LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

ideal date time format

I'm searching for the "ideal" format for storing date and time information in a csv (ascii) file.  I'm storing local time.  Let's not worry about UTC, time zones, and DST for the moment.  The application stores data at a rate between 20 Hz and every 10 seconds, so resolution needs to be 0.01 seconds.  The program has many channels, so the decision long ago was to use SGLs for internal data storage.  This precludes the use of epoch time directly (e.g. LV time seconds since 1904).  Desired attributes are:

Use as few columns as possible.  Preferably one for date and one for time.

Completely numeric format.  (e.g. HH:MM:SS.ss can't easily be parsed into a single numeric value by many programs)

Human-readable is desirable.

Adherence to known standards is desirable.

Resoultion to 0.01 sec.

Graphable.  (e.g. using time on an x axis produces an appropriate graph.  What doesn't work in this regard is HHMMSS.ss as a "numeric" value, since this jumps when hours or minutes increment.)

 

I realize some of those requirements are a bit contradictory.

 

What I am using so far, mostly, is Sec. Since Midnight of the day when data acquisition was started.  This graphs pretty well.  It keeps a single, monotonic scale if you take data past midnight.  But if you run for more than a day or two, it becomes more unwieldy.

 

As an option, I'm adding columns on the end of the file in the ISO-8601 formats of YYYY-MM-DD HH:MM:SS.ss  These are human readable and excel-graphable.  But programs that require pure numeric values will have to just ignore the last two columns.

 

I've toyed with ideas like creating an Epoch Date (e.g. days since Jan 1, 2000) to be used with Sec Since Midnight, but I don't want to go about inventing a new "standard" that no one else understands.  Also, calculating such a date in local time from LabVIEWs UTC epoch time is not straight-forward.

 

Adding Ordinal Day (similar to Julian Day) as a 2nd column with Sec Since Midnight might be a reasonable option.  This is well-behaved for 364 days of the year.

 

Some people use six columns, writing YY MM DD HH MM SS.ss separately to individual columns.  This is fairly human-readable, but not very graph-able.

 

Have any of you come up with reasonable solutions to this issue?

 

Thanks,

   DaveT

-------------------------------------------------------------
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
Certified Embedded Systems Developer
-------------------------------------------------------------
There are 10 kinds of people: those who understand binary, and those who don't.
0 Kudos
Message 1 of 4
(3,377 Views)

Hi Dave,

 

I really don't know of an good standard that would work for what you are doing. I am assuming that you are are trying to graph this in both LabVIEW and Excel. If I were in your shoes I would use the YYYYMMDDHHMMSS.ss format, since we know  this can graphed in excel and I would use the Date/Time to Seconds.vi. Below is a vi snipnet:

 

18063i60FB40E6EEF5E39F

 

Please let me know how this works out. Also how is ALARM?

 

 

Joe Daily
National Instruments
Applications Engineer

may the G be with you ....
0 Kudos
Message 2 of 4
(3,343 Views)

Joe, you can scan from string directly into a timestamp.

Use %<%your timeformatter%>t to support this, no need for the time cluster since this will mess up DST and timezones.

 

On topic I would use 8601 format since it's sortable.

 

Ton

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
0 Kudos
Message 3 of 4
(3,316 Views)

Consider the use of the Julian Day or the Modified Julian Day. You can search on the net to get explanations and examples on that time format.

 

0 Kudos
Message 4 of 4
(3,305 Views)