I have investigated this problem a bit more. I will try to explain why the Picasa Web Albums API follows a bad design decision and why the recent change in behavior made things worse than before.
As a preliminary remark I would like to report that I could neither find the described behavior documented anywhere nor could I find any announcement regarding the change of behavior. In my opinion this is not how public APIs should be maintained. Converting photo dates into timestamps, as the API does, is a bad idea because it cannot be done right. It is also a bad idea because it makes the common use case difficult and does not make exceptional use cases any easier. Any photo date refers to a timezone that is generally unknown, as Ryan Boyd has pointed out previously. A timestamp is independent of timezones. Converting a date into a timestamp requires the missing timezone information. Since it is missing, the API has to make guesses. In the past the API used to guess that the date stored in a photo refers to GMT. That is obviously wrong in most cases and so it results in a timestamp that is wrong. But it is consistent and it allows to be corrected with reasonable effort, as John McLaughlin has described. Now the API guesses that when a photo has a geotag, the photo date refers to the timezone of that place. A reasonable assumption that seems less wrong than before. But: In case a photo has no geotag, the API still assumes that its date refers to GMT. So now there is an inconsistency. In case I want to simply reconstruct the date that is stored as plain text in a photo (what I consider the common use case), I now have to go through the following procedure: 1) Obtain the timestamp 2) Check if the picture has a geotag 3a) If so, find out the timezone of that place 4a) Convert the timestamp into a date using that timezone 3b) Otherwise, convert the timestamp into a date using the GMT timezone Flickr, in contrast, just gives me the date as it is found in the file. This makes the common use case much easier. At the same time it does not make it any harder to convert the date to another timezone (the exceptional use case). -Daniel Am Dienstag, 22. Oktober 2013 20:40:09 UTC+2 schrieb Daniel: > > > Am Sonntag, 2. Dezember 2007 07:14:02 UTC+1 schrieb John McLaughlin: >> >> I tried to geotag the photo but that doesn't seem to do it either -- >> The photo timestamp stubbornly stll thinks it's in Greenwich (even >> though I've said "Hey, you are actually taken in California!) >> > > That behaviour seems to have changed now. The Picasa API now returns a > different timestamp for the same photo than some time ago. The timestamp > that is returned now seems to be valid for the timezone that matches the > geotag of the photo. > > Unfortunately it does not seem to be possible to ask the API what timezone > it has used for calculating the timestamp. So one has to perform the same > coordinate-to-timezone conversion as the API to know how to convert the > timestamp back into a date. > > Only to finally obtain the plain date that is already stored in the photo > file. > > It seems to me that the idea of converting the timezone-independent plain > date stored in the exif data into a timestamp was a bad idea from the > start. The change described above now repairs some of the defects for the > price of additional complications. > > When I look at a picture taken in New Zealand, would I ever be interested > in what time it was in Germany at that moment? > > Best regards > Daniel > -- You received this message because you are subscribed to the Google Groups "Google Picasa Web Albums API" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-picasa-data-api. For more options, visit https://groups.google.com/groups/opt_out.
