Results 1 to 3 of 3

Thread: How to parse a date/time string that may be invalid only because of DST?

  1. #1
    Join Date
    Jul 2020
    Posts
    1
    Qt products
    Qt5
    Platforms
    Unix/X11

    Default How to parse a date/time string that may be invalid only because of DST?

    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?

  2. #2
    Join Date
    Jan 2006
    Location
    Bremen, Germany
    Posts
    513
    Thanked 77 Times in 72 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11 Windows

    Default Re: How to parse a date/time string that may be invalid only because of DST?

    Parse date and time separately and add the time to your datetime later on.

  3. #3
    Join Date
    Mar 2009
    Location
    Brisbane, Australia
    Posts
    7,688
    Thanks
    13
    Thanked 1,598 Times in 1,526 Posts
    Qt products
    Qt4 Qt5
    Platforms
    Unix/X11 Windows
    Wiki edits
    17

    Default Re: How to parse a date/time string that may be invalid only because of DST?

    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.

Similar Threads

  1. How do you parse a string in qt C++?
    By brandanorama in forum Newbie
    Replies: 1
    Last Post: 26th January 2014, 21:04
  2. Fastest way to get date and time in string
    By RolandHughes in forum Qt Programming
    Replies: 1
    Last Post: 21st May 2013, 15:45
  3. Replies: 0
    Last Post: 5th January 2011, 23:21
  4. other time...can't get date
    By mmm286 in forum Newbie
    Replies: 7
    Last Post: 4th March 2010, 16:53
  5. Best way to parse a string
    By Lele in forum Qt Programming
    Replies: 3
    Last Post: 20th August 2007, 13:33

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.