Assumed time zone when parsing Exif header causing improper display of capture date/time
|
galbit
Joined: 2005-11-07
Posts: 18 |
Posted: Wed, 2006-05-17 14:24
|
|
It seems that when parsing the textual representation from the Exif header into a Unix timestamp, the server time zone is used. That is only correct if camera and server happen to use the same time zone, which is not very likely under travel and/or if your server is in a remote place. When outputting the value, the server time zone is used as well. If that hasn't changed in between, the numerical values (hours, minutes, etc.) will actually come out the same, making the problem somewhat unobvious to the casual user, but the assumed time zone which is displayed when you use %Z in your format string will evidently lead you to a wrong interpretation of those numbers. Bottomline is that Gallery cannot meaningfully convey the exact time at which pictures were taken. While this is actually a limitation of the Exif header (which lacks time zone info), things are made worse by assuming a time zone which is most likely incorrect. Either the time zone should be handled explicitly when parsing Exif data into a Unix datetime value or the string in the Exif header should be reproduced "as is" without refering to any time zone as that information is not present in the header. The former might be tricky: could be done by asking the user or by reading from a global or per-item setting. The latter probably means that a Unix datetime type cannot be used for storing the value. Changing the server time zone in config.php (as an FAQ suggests) only works if all pictures in all albums of all users use that same time zone. It would also require access to the server machine. First encountered this in version 1, but since my server administrator upgraded to version 2.1, I have found that it is still an issue. I hope that somebody can come up with meaningful feedback (I've been on version 2 for only a day now; I may have missed stuff) or that things might be fixed. |
|
Posts: 32509
please try the search engine of this website (or use google). this has been discussed already. not sure what the outcome was though.
please file a bug report if you don't find it already listed on:
http://sourceforge.net/tracker/?group_id=7130&atid=107130
Posts: 32509
topic moved.
Posts: 18
Ok, I think you mean http://gallery.menalto.com/node/42556 and nothing really came out of it. As soon as I have some time I will delve into the source to find out exactly what's happening, and try to file a bug.
But I also feel that it might require some discussion because of a design choice that has to be made: do we want to store times taken from the Exif header as-is, with an unspecified time zone and also treat them as such further down the line, or do we want to make the time zone explicit (has UI implications) so we can happily use ordinary datetime values?
Posts: 32509
i guess we should set a reasonable default and give the admin the chance to override it sine there is more than 1 reasonable approach.
i'd be glad if you could summarize the most reasonable approach(es) and we can then quickly discuss it here or during on of the upcoming g2 meetings in irc #gallery on irc.freenode.net (Thursdays 10 AM PST).
Posts: 18
As I see it, either you don't do time zones (1), or you do (2):
1. Treat the capture time from the Exif header as-is (i.e. as a value with unspecified time zone)
This implies that a Unix datetime type cannot be used. The most obvious data type to store the value from the Exif header would be a string. Just do a literal copy of what's in the header, and display that wherever it is needed. This would be the simplest solution, but changing the data type may still require code changes in a lot of different places.
2. Make the time zone explicit.
This has an air of "Right Way"-ishness about it, but is also more complicated: it would require an extra piece of meta-info for an item that gives the time zone (as a tz string) to be used when interpreting the Exif header and also the UI elements to fill it.
This extra field may be filled directly when adding items, but also needs to be editable afterwards. If left unspecified, a reasonable default would be the site's time zone (defined as the time zone that is used for displaying datetime values, currently taken from the server config but it's probably a good idea to make it configurable for site admins) so we get the current behaviour.
Taking it one step further: items could inherit this value from their parents and ultimately from the site. This preserves current behaviour if left alone, but also makes it possible for people to set a default for their albums and allowing overrides on a per-album, per-import or per-item basis. (btw the time zone used for display could be made configurable in exactly the same way, with inheritance and all. Now that would be nicely symmetrical!)
I'm not (yet) familiar enough with the Gallery2 UI to know if such a chain of inheritance would go well with G2's normal "way of doing things".
Posts: 8601
Can you post an example?
1) string in EXIF data
2) numeric unix timestamp G2 makes from this
3) your date/time format setting in site admin / general
4) your TZ setting in config.php, if any
5) string date/time that G2 displays
6) #2 and #5 if you comment out your TZ setting, if you have one
it's not clear to me where it goes wrong.. i'd think if the same TZ is assumed in each conversion then you'd see the right time.
Posts: 18
Ok, this is a bit hard for me since I'm not the server admin, and I'm not a programmer (not skilled anyway) but I'll try.
Example: photograph taken on March 1st, 2005 at approx. 19:42 PST, with camera clock referring to UTC
1) string in EXIF data: "2005-03-02 03:42:06"
2) resulting timestamp (obtained by using %s in format string): 1109731326
3) date/time format string: "%Y-%m-%d %T (%Z)"
4) can't tell TZ setting (no read access to config.php)
5) "2005-03-02 03:42:06 (CET)" (this translates to 18:42 PST...)
6) can't change TZ setting (no write access to config.php)
From this example it becomes apparent that somewhere along the line an assumption is made that the camera clock runs on CET (or the locale which is in effect for strtotime or a similar function at the time of conversion to datetime, whether that is set in config.php or elsewhere).
You are almost right in that, if the same TZ is assumed in each conversion, you get the same time. You get the same numbers (hours, minutes, seconds). However, these numbers refer to some assumed time zone, which may very well be wrong. A reason this problem goes mostly unnoticed may be that people tend to leave out the %Z from their format strings and may grow accustomed to interpreting the displayed times as "zoneless". But datetime values are not zoneless.
Posts: 8601
"camera clock referring to UTC" -- what does this mean?
if you change that statement to "camera clock assumes local time, no particular timezone given" then wouldn't all the output be correct? ie, set the clock on your camera to the correct local time ;-)
Posts: 7994
In your example, when you took the photo on March 1st, 2005 at approx. 19:42 PST, what time did your camera say? Did your camera say that the time was 2005-03-02 03:42:06? Or did your camera say that it was 2005-03-01 19:45? In short, is your camera timezone aware? If it is timezone aware, then it needs to put the timezone into the EXIF data or otherwise give us some indication that there's a timezone involved. Without the timezone we have to interpret the time in whatever timezone we have handy (the timezone of the server). We could add a feature to let you specify which timezone you prefer, but that would be complicated if you're feeding it info from two different cameras that treat timezones differently.
Posts: 18
"camera clock referring to UTC" means that the camera's clock shows UTC. So the camera said 2005-03-02 03:42:06. Had it been set to local time, the final output would have been 2005-03-01 19:42:06 (CET)" (which is even further off).
People decide for themselves what time zone they make their camera clocks refer to, but they don't tell the camera. It just doesn't know. There may be some timezone-aware cameras (haven't seen any though), but most cameras aren't even interested, and there also seems to be no standard way of storing the timezone in the Exif-header.
I don't agree that "without the timezone we have to interpret the time in whatever timezone we have handy". It could be better not to interpret at all. The current assumption that camera and server timezone/locale are the same might be reasonable as a default, but it currently isn't even a default; it's a fixed server-wide value.
So we should either acknowledge that we don't know the time zone and leave it out altogether (probably the cleanest, easiest solution), or give the user an opportunity to tell Gallery what the camera was using.
One could say "well don't use %Z in your format string then" but there really are some fundamental problems, with the potential to come back and haunt you: it will only work if the same timezone is used in both conversions (to datetime and to display format) which may or may not be the case now, and is far from guaranteed under future code changes. More importantly, it distorts the semantics of the datetime value. A normal datetime states a point in time, whereas a datetime used in this way means "time in unspecified timezone, stored using an offset determined by the TZ that was in effect at the time this value was calculated". Not very intuitive to developers that might want to use such a value elsewhere.
I would appreciate it if you could go back and read what I posted in reply to Valiant on 2006-05-24. When you regard this as a "bug", then my first point there would be a "fix". Should someone become enthousiastic and decide that proper time zone support is worth having, then the second point could provide a start for UI/design considerations.
regards
Bart
Posts: 8
I came across this thread while searching for a solution to my date/time problem. Was this ever resolved? I have a few thousand pictures which were taken in probably 10 or more timezones. I always set my camera to local time including DST if applicable. To complicate matters further, my website host is in a completely different timezone to where I live, so it looks even more wrong. If I am understanding correctly, I can change the format string to drop the timezone, since it is always wrong, and because my camera is always set to local time, it will display the correct local time (relative to where the picture was taken) without a timezone. This makes me wonder why it's displayed at all by default. That's only ever going to be the right behaviour for people who don't travel much and happen to have their website hosted in their local timezone, presumably.
Posts: 32509
Nothing has changed.
All you can set in G2 is the timezone of your G2.
FAQ: Can I change the timezone for dates/times displayed in G2?
--------------
Documentation: Support / Troubleshooting | Installation, Upgrade, Configuration and Usage
Posts: 8
OK, thanks. Because I always use local time with my camera I've just changed my format string to drop the timezone and that works fine for me, so I'm happy.
Posts: 18
steve-p, not much will happen unless people vote for a fix. Have a look at http://gallery.menalto.com/sfvote/all and donate your vote(s) to bug #1570759 to stand any chance of having this resolved.
Posts: 11
I would love to see something fancy implemented here, and will vote.
When time permits, I'll look at submitting something for it too.
Posts: 18
I noticed that someone just added the word "fix" to the summary field of bug #1570759. Yay! Just when I had given up all hope... ;-)
Posts: 18
Does anyone know if Gallery 3 finally solves this?
Posts: 7994
Unfortunately, no. Gallery 3 does not solve this. The code is available in svn-- if you'd like to patch Gallery3 to support this, let me know.
Posts: 18
Had this been a simple fix, I would have done that 3 years ago. However, as I pointed out earlier, there's a choice that has to be made about HOW to fix this, and I haven't seen any thoughts from the developers on that. So let me re-iterate:
Do you want to leave the time zone unspecified (requires changing the data type used internally for representing the date/time) or do you want to have explicit time zone info (requires extensive UI changes)? Pity this hasn't been tackled in the design phase of version 3 as that would have been a natural occasion for making such a choice. As I'm not familiar with the code base, I cannot fully oversee the consequences of either approach, except that the first is probably easier, certainly now v3 already has crystallized and solidified to beta stage.
Meanwhile, the Gallery 2 server that I use is EOL and will go dark soon. I'm setting up my own server, so I can finally implement the only reasonable workaround that I can think of: have the entire server run on UTC. Incidently, that fixes a number of problems in other software as well. Apparently crappy time zone support is quite common ;-)