Determining a Length in Seconds into Date and Time Cluster output

[emw129]

How would I go about extracting a period of time in seconds (which I believe is the default value of time since some date in 1905) using the standard Date/Time Cluster.  Which means that I want to calculate the exact period of time in years, Months, days, hours, minutes and seconds.  But When I attempt to do this manually the 1905 date throws be off by 5 years and some odd days.   Also If I try to calculate it manually, I think that I am off by a few days.  This might be a 2K year miss calculation, but I'm not sure.  Attached is a futal attempt to understand this better.  

I guess what I'm really trying to do is zero out the LabView Time start date which is some sort of 1905 arbitrary date that is considered a Time Point of Zero, from which all future dates are calculated.  See attached screenshot of my front Panel experiment to resolve this issue, where I am trying to calculate 2 Billion seconds (2G) into Years, Months, Days, Hours, Minutes and Seconds.

[Bob_Schor]

From the LabVIEW Help:

Get Date/Time In Seconds Function

current time returns a timestamp of the LabVIEW system time. LabVIEW calculates this timestamp using the number of seconds elapsed since 12:00 a.m., Friday, January 1, 1904, Universal Time [01-01-1904 00:00:00].

If you wire this function to a Dbl, you will get ... the number of seconds elapsed sing 12:00 am, Friday, Jan 1 1904 (UTC).  If I try to do the inverse, and convert Dbl 0 to a Time-Stamp, I don't get a valid conversion (in LabVIEW 2017) because I think NI "traps" this as "unwired", but if I try to convert 1 (= 1 second) to a Time-Stamp, I get 7:00:01.000 PM, 12/31/1903, but I'm in UTC -5 (Eastern Standard Time), so adding 5 hours to get UTC gets me 12:00:01 am, 1 Jan 1904 (as advertised).

I'm not really sure what it is you are trying to do.  If you subtract two TimeStamps, you'll get seconds.  If you add Seconds to a Time-Stamp, you'll get another Time Stamp (which is how you can get future Dates by adding, say, a "Week of Seconds = 60*60*24*7" to get next week's Date).

Bob Schor

[GerdW]

Hi emw,

See attached screenshot of my front Panel experiment to resolve this issue, where I am trying to calculate 2 Billion seconds (2G) into Years, Months, Days, Hours, Minutes and Seconds.

Unfortunately a front panel image doesn't tell us anything about your code…

As Bob explained it's quite easy to add seconds to a timestamp:

[emw129]

Using Time Stamps I'm trying to calculate how long a given number of seconds are, for example if I want to know how long 2G (2 Billion) seconds happens to be, I should be able to do some kind of math of simply converting 2 Billion seconds into Time stamp, how ever the only constant for the origin of the time stamp should be "Zero", but that only gives me 12am, January 1,1904, ... which pusts my caclulation off by 4 years.  

What should be the Time/date stamp formula for simply getting a span of time in Months, Days, Years, Hours, Minutes, Seconds out of Time Stamp?  That January 4th start time has no constant from which to calculate back 4 years.

I suspect the reason they made January 4th, 1904 the start Date/time was because 1900 should of been a Leap Year, but Leap Years are always skipped on the end of every Century, unless that Century is evenly divisible by 400 years.  Making Date and Time keeping unstable.  The reason for this rule is because a Year is not exactly 365 days and 6 hours.  But instead is 365 days 5 hours, 48 minutes and 46 seconds.  That few minutes off from 6 hours is why Leap Year is skipped at the end of a century and not skipped if the Century is evenly divisible by 400 years.

[emw129]

That seems to be a more simple sollution that I created... Let me see what happens if I change the date time cluster constant to January 1,1900 at 12am (Remember that 1900 should of been a Leap year, but actually should not of been, because each Century # skips Leap Year unless it is evenly divisible by 400 years)

[emw129]

When I use your calculation and I replace the Date Time constant with January 1,1900 then add 2G seconds the result is 1963 years 5 months 19 days 5 hours 33 minutes 20 seconds.  (I know if I remove the 1900 I get 63 years 5 months 19 days 5 hours 33 minutes and 20 seconds)

When I manually calculate it out I get 63 Years 4 Months 15 Days 10 Hours 9 minutes and 26 seconds.  

So which way is the correct Answer?

I have the VI that makes this calculation attached to this message, plus the Project that calculates other details from this one sub-vi

[GerdW]

Hi emw,

atleast I would NOT calculate with fixed month length of 30 days as you do!

And I trust LabVIEW timestamp calculations for dates after 1904…

[Bob_Schor]

---

@emw129 wrote:

Using Time Stamps I'm trying to calculate how long a given number of seconds are, for example if I want to know how long 2G (2 Billion) seconds happens to be.

---

Well, you can do this two ways, and get two slightly different results.  The first is to simply take 2 billion (which is, itself, ambiguous -- there are two definitions accepted, you can "look it up") and do "Number to Time Stamp" and get 11:33:20 PM, 5/17/1967 (using the 2^9 definition).  The problem is a "feature" of "Number to Time Stamp" that doesn't compute Time Stamp 0, so "cheat" -- compare 2G + 1 with +1 (which, in Eastern Standard Time, is 7:00:01 PM, 12/31/1903).

The other thing to do is to get successive remainders/quotients.  Divide 2&9 by 60 to get seconds and minutes, divide minutes by 60 to get minutes and hours, etc.  But what happens when you have days and want months?  I divided by 365/12 (ignoring Leap Years, but I could have used 365.25, or 365.2425) to get "average months", then divide by 12 to get months and years.

Of course, this will be highly dependent on the initial day and on such things as "local time zone" (think Daylight Savings vs Standard Time), meaning the question is not "well posed".

Computing 2 Billion Seconds

Bob Schor

P.S. -- if you don't have LabVIEW 2017 or 2018, you could just "program" this Snippet yourself.

[emw129]

I actually don't assume 30 days per month, I normally only look at how many days were in the previous Month, that usually works out more exact than assuming some 30.## number of days in a month.  However my calculation usine Time/Date Cluster seems to reveal a different length of time, compared to if I manually calculate it out.

[emw129]

365/12 seems to be a more sane approach