06-08-2009 04:37 AM
Solved! Go to Solution.
06-08-2009 06:40 AM
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.
06-08-2009 09:48 AM - edited 06-08-2009 09:49 AM
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...
06-08-2009 10:31 AM
06-08-2009 10:50 AM
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.
06-08-2009 11:24 AM
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.
06-08-2009 11:25 AM - edited 06-08-2009 11:33 AM
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.
06-09-2009 04:02 AM
06-09-2009 08:38 AM
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)
06-09-2009 09:05 AM