LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
DFGray

Timestamp Conversion Primitive

Status: New

There are a plethora of timestamp formats used by various operating systems and applications. The 1588 internet time protocol itself lists several. Windows is different from various flavors of Linux, and Excel is very different from about all of them. Then there are the details of daylight savings time, leap years, etc. LabVIEW contains all the tools to convert from one of these formats to another, but getting it right can be difficult. I propose a simple primitive to do this conversion. It would need to be polymorphic to handle the different data types that timestamps can take. This should only handle numeric data types, such as the numeric Excel timestamp (a double) or a Linux timestamp (an integer). Text-based timestamps are already handled fairly well. Inputs would be timestamp, input format type, output format type, and error. Outputs would be resultant format and error.

11 Comments
Mr._Jim
Active Participant

A very, very good idea.  I always have to hunt arond to find the right standard for whatever I'm doing.

JÞB
Knight of NI

Yes it can get difficult even when only considering excel

 

The problem scope gets worse when you realize that not only is the excel epoch zoneless it has a boolean flag in each workbook to adjust it as well so, 0 can be one of 50 times if converted to UTC 25 of them within a day of mightight jan 0 1900 and another 25 grouped around jan 1 1904.


"Should be" isn't "Is" -Jay
NickNZ
Member

http://en.wikipedia.org/wiki/ISO_8601

LabVIEW week doesn't match week of year on calendars - worte code to work around that at one point.

 

And then there is DD/MM/YY vs MM/DD/YY.

Which caused me some real fun with US dates in a Excel workbook on a DD/MM/YY local PC.  The formula I used for reference in Excel is...

IF(ISNUMBER(A3),DATE(TEXT(A3,"yyyy"),TEXT(A3,"dd"),TEXT(A3,"mm")),DATE(RIGHT(A3,4),LEFT(A3,FIND("/",A3)-1),MID(A3,FIND("/",A3)+1,2)))

 

And then i had to turn a time stamp into a string to download to a UUT, then read it back and convert back to compare clock drifts... Windows XP handles a daylight saving flag differently to Win 7 arrah...

 

 

RavensFan
Knight of NI

Where does LabVIEW provide a Week of Year function that you can compare to a calendar?

 

As for MM/DD vs. DD/MM, both LabVIEW and Excel work with numerics.  Excel as the number of days since Jan 1, 1900 (give or take) and LabVIEW as the number of seconds since Jan 1, 1904.  Unless you are doing conversions between LabVIEW and Excel using string functions, then it doesn't matter now a date is displayed.

 

As for Win7 vs. XP, you're going to have to explain more about how they handle daylight savings time differently.

crossrulz
Knight of NI

When formatting the time as a string, there is %W for the week of the year.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
RavensFan
Knight of NI

Okay.  I wasn't thinking about those format codes.  I just know date/time record didn't have week of year as part of the cluster like it has day of week or day of year.

JÞB
Knight of NI

As for Win7 vs. XP, you're going to have to explain more about how they handle daylight savings time differently.


Its not really the OS.  The VEEPs house staff changed some things and that upset a few carefully calculated lookup tables in some OS's. 

 

Yes, the US Naval observatory is the official residence of the US Vice President.  USNO is also the authority on maintaining civil time in the USA and its territories.  (And you thought the VP couldn't really mess with your code- He can!)

 


"Should be" isn't "Is" -Jay
RavensFan
Knight of NI

There were patches to XP when the daylight savings time dates changed a handful of years ago.

PhillipBrooks
Active Participant

It's been a couple of years since I touched this, but created this VI for creating an 8601 timestamp. I didn't finish a parser for 8601.

 

It includes a fix for the week number discrepancy between ISO and NI (which I thing is actually a Windows problem).

 

https://decibel.ni.com/content/docs/DOC-7199

 

 


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

Bluegraf
Member

There is also an issue with the DST status. Ever tried to find out the difference between your loal time and UTC/GMT?

The computer alyways seems to know for which timezone it is configured but never whether it is summer or winter and keeps asking for the DST state. Where is your code supposed to get this information from?

 

Today I got one solution from support:

http://digital.ni.com/public.nsf/allkb/27835BBF3614FF5B86256E310076F196

It works but... isn't that an evil hack?

 

I'd really like to see a function: (in pseudocode) GetCurrentTime( [LocalFromComputerSettings / UTC / TimezoneDefinedByYou] )