Counting days. Interrelation between Timestamp and Cluster of time values

[_Y_]

The Timestamp difference between the same time of different dates is not necessary a multiple of 86400 (seconds in 24 hours). The reason is in the daylight saving jumps that are internally accounted. However, if there is a need to count days (not seconds) an inconvenience can occur. For example, the output of such comparison is FALSE:  

I tried to deal with the problem converting between Timestamp and Cluster of time. However, the conversion gives strange results. Take this as an example:

   12:00 of the Cluster results in 13:00 of the Timestamp. 

The problem can be easily solved using conversion to string:

   but this is an ugly solution. Is there a conventional way to work with dates?Can I find somewhere a good description of conversions between Timestamp and Cluster of time? Thank you.

[jon_mcbee]

Hi Y,

I am not sure I understand your question.  I think the reason your date time rec cluster did not give you what you expected in your timestamp is because you did not set the DST field to 1.  Does this answer your question?  If not, walk me through the problem you are having.

[smercurio_fc]

The output of the comparison example you had posted gives True on my computer (using LabVIEW 8.2). However, I would caution you that you are dealing with floating point values, and the caveats about using the Equal? (or Not Equal?) function on floating point values should be understood. I.e., don't use that function on floating point values.

[_Y_]

jmcbee, smercurio…, Thank you for the replies. Probably my post was not sufficiently clear because I try to discuss two interrelated questions: i) "How LabVIEW deals with conversion of time scale?" (a broad subject) and ii) "What is a good way to deal with dates only?" (practical problem).

smercurio…, this is not a floating point problem. I tried different couples of dates also indicating DBL values. The problem is caused by the daylight saving jumps.

jmcbee, yes, if DST is set to 1 this conversion is ok but conversion for 2009-03-28 (for example) needs a manual set of DST to 0. So, I have to deal with the same problem – with the need to know when a government (king, dictator, referendum) of a country decides to shift sun in the skies

The particular problem is quite simple. I want to operate (plus, minus, etc.) with a scale of days and be able to see corresponding dates in GUI. As a fact, I already solved the problem (the idea is in the third diagram of the first post). I operate with objects where the internal representation is numerical while interactions with GUI are performed using the string-conversion procedures. The jumps are only plus-minus1 hour; if the reference is 12:00 the "string-rounding" always results in the same day.

This approach can be a "quick-fix" but, to my feeling, a more reasonable way should exist.

[_Y_]

This is an example illustrating my question. The program answers "Was a rain two days ago?" using the Timestamp scale.    The green SubVI contains:    Please, do not advise me on improvement of this particular "program" (I already know about the Wednesday rain). This is only a very simplified illustration.

[Davidek]

Hi Y

This may be a sidetrack, but I've always found that when working with dates it's easier to convert them to Julian Day. Then you can easily subtract, add or compare dates in a rubust way. Maybe that is something to consider? Attaching a VI that converts to Julian Date (Julian Day plus time in fraction of a full day).

Best Regards

David