Quote Originally Posted by rlk View Post
I'm a developer on KPhotoAlbum, a volunteer open source image management application for KDE. We recently received a bug report from a user because some of the person's photos were not getting the date extracted correctly from the EXIF data embedded in the photograph.

The date/time in a photo is, per the EXIF specification, encoded as

YYYY:MM:DD hh:mm:ss

The problem was one of the photos had a date string of

2000:04:02 02:05:37

This fell within the spring-ahead that year.
Unfortunately the EXIF spec does not specify the time zone that the time stamp represents.

If the camera was recording local time then it must have some idea of a timezone (i.e. to derive it from GPS with/without DST) or be a naïve clock with no concept of timezone or DST at all. Since the camera recorded 02:05:37 then its idea of the time did not include DST and in my view you should parse it using a time zone without DST (e.g. UTC+10:00 instead of Australia/Sydney). You need to know the timezone in the location, and at the time, the photo was taken (not the viewers current time zone). If you also have the GPSTimeStamp and GPSDateStamp metadata then you could derive a time offset (non-DST) to work with. I don't know how you perfectly determine the correct time zone if the camera has not also recorded it.

If the camera is recording UTC (or GPS time) then there is no DST, and 02:05:37 is perfectly valid.

The forensic argument is fine, but a lawyer would have a field day with this gloriously ambiguous EXIF timestamp (digitally signed or not) if the GPS data is not also present. I guess you could display both the original file string and the date/time as you have interpreted it with an explicit time zone shown.