rlk
11th July 2020, 22:51
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. As a result, the attempt to parse the string as a date yielded an invalid date, as documented. Even much more recent cameras don't automatically correct for DST (which would be problematic, among other reasons as it would require a firmware release whenever the timezone rules changed anywhere). But the result is that if you're taking photos during just the wrong hour of the year we aren't able to extract a timestamp and have to fall back on the file modification time.
Obviously, this is a rather rare situation. I've personally never hit it in the something like 300,000 photos I've shot, since I've never been out shooting at 2 AM on a certain Saturday night in the spring. Still, if there's a robust way of working around it I'd like to be able to do something. One thought that came to mind is if the parser fails to append a 'Z' to the timestamp string (to indicate UTC) and try again; if it succeeds, it's clearly an indication of a DST problem. We could then either accept the UTC time as the timestamp, or if we can somehow work out the timezone, correct for that. Fiddling with a timestamp string is not the most robust approach, however.
We'll probably simply document this as a corner case and recommend that people manually adjust the timestamp of their image files. That's not going to be to everyone's liking; one of the big draws of KPhotoAlbum is that it does not modify your image files in any way. It won't be acceptable, for example, to people using cameras that sign image files for forensic purposes, since the EXIF data is included in the signature.
Thoughts?
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. As a result, the attempt to parse the string as a date yielded an invalid date, as documented. Even much more recent cameras don't automatically correct for DST (which would be problematic, among other reasons as it would require a firmware release whenever the timezone rules changed anywhere). But the result is that if you're taking photos during just the wrong hour of the year we aren't able to extract a timestamp and have to fall back on the file modification time.
Obviously, this is a rather rare situation. I've personally never hit it in the something like 300,000 photos I've shot, since I've never been out shooting at 2 AM on a certain Saturday night in the spring. Still, if there's a robust way of working around it I'd like to be able to do something. One thought that came to mind is if the parser fails to append a 'Z' to the timestamp string (to indicate UTC) and try again; if it succeeds, it's clearly an indication of a DST problem. We could then either accept the UTC time as the timestamp, or if we can somehow work out the timezone, correct for that. Fiddling with a timestamp string is not the most robust approach, however.
We'll probably simply document this as a corner case and recommend that people manually adjust the timestamp of their image files. That's not going to be to everyone's liking; one of the big draws of KPhotoAlbum is that it does not modify your image files in any way. It won't be acceptable, for example, to people using cameras that sign image files for forensic purposes, since the EXIF data is included in the signature.
Thoughts?