LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

daylight saving and Date/Time to seconds

Solved!
Go to solution
Judging from some other posts this is a long running issue.

Using LV 8.6 by the way.

I am trying to convert an time/date to LV timestamp format using the 'Date/Time to Seconds' vi. Recently converted time has been being displayed as an hour ahead (I am in UK & DST is now in effect) - a problem I thought I had cured.

I wrote a simple test program for the VI (create a constant from the input and use that to drive a bundle by name cluster to set sec/hour/day/month/year etc. With the function in a loop(0.5s) I have controls to change month and isDST in the record & isUTC in the function call - and displays of the output as a timestamp and as EXT. If the month is pre-DST all is ok (eg an hour of 10 stays at 10) if the month is 5 (DST) then the hour goues to 11 - unless isDST is set to 1 and isUTC set false. but when that combination of controls is used with the month set to 2 - the hour becomes 9.

As I say I thought I had cured this and remembered something about the Windows DST flag - and I had recently swapped PCs - so I turned off the Windows DST (wDST) - no effect. This morning I rebooted the PC to look again at this program - to my amazement the 'problem' had gone. I then checked the wDST it was still off. I stopped the test VI and closed it and turned wDST on when attempting to reload the test VI I got a very odd error message telling me my VI on disc did not match 'part of LV in memory' and inviting me to 'revert'. I shutdown LV completely restarted it and got the same effect. I rebooted the PC and the 'revert' had gone and the problem returned (wDST ticked).

So my original fix had been to turn off wDST on my original m/c.

However my query is what is the point of the isUTC parameter of Date/Time to seconds - it seems to do nothing like what it promises. Also what bit of LV hangs about after I have closed the program presumably remembering the Windows DST setting - possibly wrongly?
0 Kudos
Message 1 of 12
(8,653 Views)

The behaviour that you are seeing regards time zone conversion is as I would expect.

 

The date/time rec to seconds function [which appears to be based on the C/Unix function mktime()] converts the time that you specified into a timestamp. Part of the information within the cluster is whether this time is in standard or daylight saving time (GMT or BST to you and me). If you set this value to either 0 or 1, you are telling the function whether or not this time is "daylight savings" regardless of what is actually in effect on that date.

 

On the output side the timestamp is displayed using the timezone and DST correction in force on your PC for the time value in the timestamp.

 

Therefore if you do you date/time rec to seconds calculation with either
1) BST in effect and DST set to 0
2) GMT in effect and DST set to 1 (or any positive value)

the timestamp will be one hour wrong, and hence your display will be an hour out.

 

While in the UK time zone, the effect of setting the DST flag in the date/time rec to zero and of setting the isUTC input to the convert routine will be the same. Those with a PC set to New York time zone will find that (ignoring DST!) setting isUTC will apply a 5 hour offset.  (Pedantry: will prevent the normal 5 hour offset from being applied - the timestamp is seconds since the epoch where the epoch is defined as a particular time in the GMT time zone)

 

 

However, there is an answer. Leave isUTC unwired (or false). Set DST to -1 (ar any negative value), and the system will (in the words of the FreeBSD man page for mktime) "attempt to divine whether summer time is in effect..."

 

Rod.

Message 2 of 12
(8,628 Views)

Rod wrote:
...

 

However, there is an answer. Leave isUTC unwired (or false). Set DST to -1 (ar any negative value), and the system will (in the words of the FreeBSD man page for mktime) "attempt to divine whether summer time is in effect..."

 


 

We just recently discovered the "-1" option when upgrading some code from LabVIEW 7.0 to 8.6.  The old Date/Time to Seconds is replaced with a compatible VI that contains the only documentation that I've seen for this behaviour.

 

I've attached and image of the block diagram...

 

 

Message Edited by Phillip Brooks on 06-08-2009 10:49 AM

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

Message 3 of 12
(8,600 Views)
Thanks to both of you, the isDST(-1) does precisely what I need - maybe NI should add it to the doc'n of Date/Time to seconds. NI help told me that the isDSTand isUTC applies to the input record data fields and that whether the output is adjusted for DST is dependant on the Windows DST setting which IMO is not explained very explicitly in the help. Clearly isDST(-1) overrides the Windows flag?

I think the 'revert' problem is something to do with changing the Windows flag so that 'time' changes and LV thinks something is out of sync between files & memory - but that is an aside.

Thanks again, Ian
0 Kudos
Message 4 of 12
(8,589 Views)

Hi All,

 

Good afternoon and I hope your well today.

 

Ian also contacted NI Support about this, and I have to say - I was unaware of the -1 conclusion. I have since found a Corrective Action Request - #42113 that concludes the NI Help file should be updated.. and suggests that this is already in-place. But I was unable to locate this. If anyone else could confirm that the update doesn't appear then I can apply this feedback. 

 

I am not sure I agree that the DST(-1) overrides something.. its just the way the function behaves - i guess the maths doesnt work, and hence it decides to add or remove nothing. 

 

I will investigate the revert issue you've mentioned. 

 

Thanks for all the info sharing! Keep up the good work. 

Kind Regards
James Hillman
Applications Engineer 2008 to 2009 National Instruments UK & Ireland
Loughborough University UK - 2006 to 2011
Remember Kudos those who help! 😉
0 Kudos
Message 5 of 12
(8,582 Views)

Hi All,

 

I have since found out that the alteration has been make for a future release of LabVIEW. The edit is planned to read,

 

is DST indicates whether the time is standard (0) or daylight savings time (1). You also can set is DST to -1 to have the VI determine the correct time automatically each time you run the VI. If is UTC is TRUE, the function ignores the is DST setting and uses Universal Time. 

Kind Regards
James Hillman
Applications Engineer 2008 to 2009 National Instruments UK & Ireland
Loughborough University UK - 2006 to 2011
Remember Kudos those who help! 😉
Message 6 of 12
(8,576 Views)

IanR99 wrote:
Clearly isDST(-1) overrides the Windows flag?




That's not the way I saw it. I see it as...

isDST < 0 : Use the Windows' idea of when a date/time needs DST to applied

isDST = 0 : Never apply DST

isDST > 0 : Always apply DST (even in winter)

 

   EDIT: Overlapping messages - I note that this is how the function operates, and the docs will be updated

 

 

It appears that a timestamp indicator implicitly uses isDST=-1, so uses Windows'  rules in converting from a timestamp to a human-readable version.

 

The isUTC flag over-rides everything, so no time zone or DST adjustments, ie the time is assumed to be in GMT, (and isDST is ignored) - c/f Unix gmtime()

 

But I agree that the documentation needs looking at.

 

I only discovered the isDST=-1 trick because my Unix knowledge screamed out that the cluster and functions had the appearance of being Unix-based!

 

 

 PS The help files are also wrong in the description of the use of "day of year" and "day of week" These fields in the cluster are *always* ignored in "date time to seconds" - they are actually set in the counterpart function "seconds to date time"

 

Rod.

 

 

Message Edited by Rod on 06-08-2009 05:28 PM
Message Edited by Rod on 06-08-2009 05:33 PM
0 Kudos
Message 7 of 12
(8,575 Views)


isDST < 0 : Use the Windows' idea of when a date/time needs DST to applied

Not sure how that works - or James' interpretation.

With Windows DST set on and an input hour set to 10 we get:

Month:2 isUTC:F isDST:0 output:10
Month:2 isUTC:F isDST:1 output:09 (10 - zone)
Month:2 isUTC:F isDST:-1 output:10
Month:2 isUTC:T isDST:0 output:10
Month:2 isUTC:T isDST:1 output:10
Month:2 isUTC:T isDST:-1 output:10

Month:5 isUTC:F isDST:0 output:11 (10 + zone)
Month:5 isUTC:F isDST:1 output:10
Month:5 isUTC:F isDST:-1 output:10
Month:5 isUTC:T isDST:0 output:11
Month:5 isUTC:T isDST:1 output:11
Month:5 isUTC:T isDST:-1 output:11

With Windows DST off - all combinations give the output 10.

So the only combination that gives 10 out consistently is isUTC:F isDST:-1 - but why?

From the help isDST is ignored if isUTC is True - that is obvious from the above - so the Windows DST is applied appropriately as seen.

When isUTC is false then isDST comes into play
if it is 0 (standard time) then the VI needs to add the DST as appropriate
if it is 1 (DST) then the VI seems to deduct the DST value and re-apply DST - how else for the 9 above?
if it is -1 (meaning??) then if the 'uses the Windows idea ...' would surely lead to an 11 when in month 5 with wDST on?

It is either 'luck' that the code works out or -1 must suppress the Windows DST - discuss??

I did wonder about the isDST value being added or subtracted from hour but that does not work out - either logically or for other timezones or for values other than 0,1,-1 so that is a dead end.

Thanks to all contributing - Ian
0 Kudos
Message 8 of 12
(8,529 Views)

Hi Ian,

 

Thanks for the post.

 

I want to try at summaries how I feel this works - in my mind. 

 

UTC = True - the time stamp IS the UTC time, then using windows DST/Timezone information the Output will be adjusted accordingly (+1 in summer for GMT)

 

UTC = False - we then look at the DST input (from the cluster) and the windows DST/timezone information.

 

When this is false, we are saying the inputted timestamp is in the local timezone - according to the windows machine, so currently the UTC time is 9 AM. Because, according to windows I am in DST and GMT.  If windows DST is false, then the local timezone inputted timestamp is the UTC time and hence nothing happens. 

 

So, if windows DST is True - adjust the timestamp then we the function also looks at the Cluster DST value.

Cluster DST = 1 - we are now saying that the inputted timestatmp has already been adjusted thus the timestamp is the UTC time. Hence the time remains 10.  (UTC = 9AM)

Cluster DST = 0 - means the time stamp is the UTC, hence 10 + 1 hour (11AM) during Month 5. 

Cluster DST = -1 - means not to adjust, even if windows says to.

 

This is why you saw that UTC:F DST:-1 and windows DST True was the only result that didn't change anything. Because if your Windows DST is True, Timezone is GMT, Cluster DST is -1 and timestamp is 10 AM  you are saying the timestamp is not the UTC time, it is in local time and then because Windows DST is true, the function looks to adjust the time stamp - and as you have manually set the DST to -1, no changes are calculated. 

 

Note: The windows machine will never set Cluster DST to -1, when Windows DST is false - DST is always 0. Then when Windows DST is true, depending on the date (and timezone) DST is 0 in the winter and 1 in the summer. 

 

"if it is 0 (standard time) then the VI needs to add the DST as appropriate
if it is 1 (DST) then the VI seems to deduct the DST value and re-apply DST - how else for the 9 above?
if it is -1 (meaning??) then if the 'uses the Windows idea ...' would surely lead to an 11 when in month 5 with wDST on? 
"

 

With Windows DST set on and an input hour set to 10 we get: (Timezone GMT)

 

Month:2 isUTC:F isDST:0 output:10  * Timestamp is local time, DST = 0 means its UTC time, look at month = winter - hence do nothing.

Month:2 isUTC:F isDST:1 output:09  * Timestamp is local time, DST = 1 means its already adjusted, look at month - winter, hence undo DST so timestamp matches local machine timezone (Currently GMT + 1)

Month:2 isUTC:F isDST:-1 output:10 * Timestamp is local time, DST = -1 means don't care. No change. 

Month:2 isUTC:T isDST:0 output:10  * Timestamp is UTC. Timezone/GMT- winter, thus do nothing. (ignore DST)

Month:2 isUTC:T isDST:1 output:10  * Timestamp is UTC. Timezone/GMT- winter, thus do nothing. (ignore DST)
Month:2 isUTC:T isDST:-1 output:10 * Timestamp is UTC. Timezone/GMT- winter, thus do nothing. (ignore DST)

Month:5 isUTC:F isDST:0 output:11  *
Timestamp is local time, DST = 0 means its UTCtime, look at month = summer - hence + 1 hour

Month:5 isUTC:F isDST:1 output:10  * Timestamp is local time, DST = 1 means its already adjusted, look at month - summer, hence the timestamp matches the current local machine timezone settings, hence do nothing.
Month:5 isUTC:F isDST:-1 output:10 * Timestamp is local time, DST = -1 means do nothing. We don't want any changes.
Month:5 isUTC:T isDST:0 output:11  * Timestamp is UTC, 
Timezone/GMT- summer, + 1 hour (ignore DST)

Month:5 isUTC:T isDST:1 output:11  * Timestamp is UTC,  Timezone/GMT- summer, + 1 hour (ignore DST)
Month:5 isUTC:T isDST:-1 output:11 * Timestamp is UTC,  Timezone/GMT- summer, + 1 hour (ignore DST)


In conclusion, your aim was to have timestamp data that was indepedant of the windows setting. The way LabVIEW time functions are designed this isn't possible. Without adjusting the overeal system time/timezone/GMT configuration the best solution is to alter the DST to -1, as discussed.
Kind Regards
James Hillman
Applications Engineer 2008 to 2009 National Instruments UK & Ireland
Loughborough University UK - 2006 to 2011
Remember Kudos those who help! 😉
0 Kudos
Message 9 of 12
(8,512 Views)


Cluster DST = -1 - means not to adjust, even if windows says to.

That is an interpretation I am happy with.
0 Kudos
Message 10 of 12
(8,503 Views)