How to parse local time from a string

[Dave_Thomson]

   A fairly common issue that I come across occurs when a LabVIEW program needs to read in a text-based data file that some other program (or even just another LabVIEW program) wrote.  Often, timestamps will be written to the file in some verison of a human-readable form, and often (unfortunately) in local time, rather than UTC.  When dealing with the data in LabVIEW, one wants a timestamp that LabVIEW can use for graphing, etc.  E.g. it should ideally be the LabVIEW timestamp data type, based on the 1904 epoch, and in UTC.  The screen shot below shows one way of dealing with this.  The parsing shown is specific to the assumption that the date and time are saved in "YYYYMMDD,seconds" format, but the parsing could be adjusted to handle any particular formatting, even named months.  In any case, the parsing pulls out month, day, year, hours, minutes, and seconds, which are then used to create a time cluster.  LV then does the difficult part of converting that to a timestamp.  The issue, of course, is that the original file writer didn't bother to save a DST indicator (or a time zone, for that matter).  So, ignoring DST, you see in the example that the first timestamp LV comes up with is clearly off by an hour.  Although the text says 36001 seconds, which is one second after 10 am, LV returns a time of 11 am.

    The next bit of logic checks exactly that.  It asks what the DST was on the date that LV figured out, then reconverts the time cluster to a timestamp using that DST value.  Which appears to give the correct value.  But even this code will have some edge cases on the days when DST changes.  E.g. the first time estimate could end up coming out in the wrong DST domain, and thus not get corrected properly.

    One minor improvement on this would be for the file writer to include the DST value (and preferably the Time Zone: the example shown only works if the file writer and reader were in the same time zone when the file was written and read!).  Even then, though, there is an inherent problem with writing local time as text.  For two hours a year (something like 2:00 am the morning of the fall transition) there are two hours of ambiguous local times, when the naming of the time is the same for the two hours.  (Is there some arcane standard for writing those times?   I suppose it would be 2:01 AM DST for the first time and 2:01 AM Std for the second.)

    Anyway, the question is, has anyone else had to deal with this problem?  And if so, what solutions have you found?

Thanks,

     DaveT

[Ben]

These two thread may help.

http://forums.ni.com/t5/LabVIEW/VI-of-the-Day-8-21-09/m-p/969872#M434878

and

http://forums.ni.com/t5/LabVIEW/The-quot-Date-Time-to-Seconds-quot-function-isn-t-working-as-I/m-p/1...

I had to resort to a "trial and error" add one second at a time in a loop and test the return value to handle challenge presented by DST (Ben Franklin, you clever fellow, you complicated out lives!)

My challenge was to schedule a "backup" for the next day at the same time. When that time is 2:00 AM I discovered (via a bug report from my customer the week following a switch to/from DST) that;

There is one day of teh year that has 23 hours and another that has 25 AND I cannot predict which week-end because I can not predict what the people in DC are going to do.

Roll into that mix that Windows shows file creation time in the current DST state (the hour the file was created will change by one hour when you move to/from DST) and you have a sticky mess.

Ben

[Dave_Thomson]

Thanks, Ben.  Those are good links to review.  And your situation is another great example of how difficult time can be.

Cheers,

    DaveT

[a_clucker]

Hi Dave,

Thank you for posting this excellent discussion of time stamps and DST. I've worked with time stamps a decent amount, and you've summed up a great amount of knowledge in one post. I've poked around the web a bit, and the best thread I can find on rebasing a clock for DST is on StackOverflow. It seems like it could fall into either a LabVIEW discussion or a general programming discussion. Also, thanks to Ben for the addition to this thread.

Thanks,

Andrew

There are 10 kinds of people: those who understand binary, those who don't, and those who don't expect a base 3 joke.

[Dave_Thomson]

Andrew,

   Thanks for the excellent links.  I was unaware of the DST = -1 option, which (I believe) is just what I needed.  It is indeed now documented as the other thread indicated.  I just hadn't gone to the documentation recently enough.

DaveT