02-05-2019 10:08 AM
Simply send your 'seconds' value to a DBL indicator, and format that indicator to show relative time.
02-06-2019 08:33 AM - edited 02-06-2019 08:34 AM
However that only produces a date that is with respect to January 1st,1904, not the actual length of time. That method adds about 1904 years to the intended value that I want. How do I zero out that 1904 years?
02-06-2019 08:36 AM
@emw129 wrote:
However that only produces a date that is with respect to January 1st,1904, not the actual length of time. That method adds about 4 years to the intended value that I want. How do I zero out that 4 years?
Set the format of the DBL indicator to Relative Time.
02-06-2019 09:24 AM - edited 02-06-2019 09:25 AM
@emw129 wrote:
However that only produces a date that is with respect to January 1st,1904, not the actual length of time. That method adds about 1904 years to the intended value that I want. How do I zero out that 1904 years?
This makes no sense. There is no 'actual' time. Time has a reference. It is relative. LabVIEW uses January 1, 1904 as its time reference. Other systems may use January 1, 1970, or something else altogether. What are you trying to accomplish?
02-06-2019 09:54 AM
I agree with the Numeric indicator, shown as Relative. Else this is a solution:
/Y
02-06-2019 10:01 AM - edited 02-06-2019 10:19 AM
Oh! Ok I get it. Yes, I agree with paul_cardinale and Yamaeda.
EDIT: Of course if you're trying to get an accurate count of months, days, etc., there's no great way to do that since that is dependent on start time/date. Yamaeda's solution essentially pretends that start year doesn't matter.
02-07-2019 07:41 AM
That seems to be pretty clean cut and forward.
In the program I wrote the projected date appears to work because my daughter turned exactly 1 billion seconds old on August 20,2018 ... which we celebrated ... (Kind of kookie) ... but the "age in seconds" rolled over on the exact year, month, day, hour, minute and second that the date cluster predicted. So the Date Time Cluster (Number) appears to be holding on to the correct time/date.
02-07-2019 07:51 AM
@Mancho00 wrote:
Yamaeda's solution essentially pretends that start year doesn't matter.
Yeah, as I understood OP the question was "how long is X secs in years, days, hours" and so on. To use my solution you also need to decrement month and day with 1 which will be apparent if you convert 0 secs. 🙂
It's a 'lazy' way to avoid the "Let's use Quotient and Remainder with different values" but it have the slight side effect that it should compensate for leap year, whereas the Q&R version should technically use 365,25 days/year, but I've rarely seen anyone use that. 🙂
/Y
02-07-2019 08:08 AM
This'd be a solution for converting seconds to Days et al with 365,25 days. I skipped months with the average of 30,44 days (for that very reason), but it should be easy enough to add.
/Y
02-26-2019 09:35 PM - edited 02-26-2019 09:41 PM
OK, what am I doing wrong here? At exactly 2 Billion seconds old (2G) the expected length of time is one day further in the future than the actual measured 2 billion seconds of age in the lower right part of the picture. The predicted date and Measured age are exactly equal, but the expected age (Age in Seconds Length of Time) is off by 1 day. See attached zip file with the high level vi being "When is.vi": Is this because we had a Leap Year in 2000 when we shouldn't of had? (At the end of every century we skip leap year, unless the century is evenly divisible by 400)