From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Handling time changes when graphing existing data


That system, which creates the files I'm reading, was written by very good programers with years of experience writing code for stuff you may use (or drive) every day. They don't just make stuff up or pretend. 


But they've not heard of UTC, Universal Standard Time?  Record the timezone offset of the data and correct for it.  Then you have the actual time to line things up with.  Local-time differences is a long-solved problem (older than computers I think; the railway engineers did it).

0 Kudos
Message 21 of 24
(792 Views)

Yes we've all heard of utc. The system allows the user to change the date and time anytime they want and must account for that. We've even had our people set the time wrong and caused duplicate date/time entries. They use the event sequence index to account for it. The system is stand alone and not on a network where you could synch the time, which would be nice.

 

Now, you could argue to not let the user change the time, but I'd direct you to marketing. It was something they wanted,  just to make things this fun.

0 Kudos
Message 22 of 24
(786 Views)

@drjdpowell wrote:

That system, which creates the files I'm reading, was written by very good programers with years of experience writing code for stuff you may use (or drive) every day. They don't just make stuff up or pretend. 


But they've not heard of UTC, Universal Standard Time?  Record the timezone offset of the data and correct for it.  Then you have the actual time to line things up with.  Local-time differences is a long-solved problem (older than computers I think; the railway engineers did it).


slightly OT but I'll tie it back to useful information.  

;

Sigh  "Local-time differences is a long-solved problem (older than computers I think; the railway engineers did it)."

Not really, the abacus could be considered a computer.  Worse, the way RR Engineers "Solved" local time differences was to add or subtract 4 minutes for each degree of longitude and publish the timetables in a manner that so confused the riders and workers that the safety of everyone was compromised.  A RR section worker would darned near need a sextant and a cloudless day along with his timetable to predict when the train would come along and kill all the people nearby if the signalman missread the timetable.  A totally "British" way to complicate things.  Luckilly, the American Vice president realized his residence (US Naval Observatory) actually had a functional component.  Timezones were adopted and adjustments between civil time and celestial observations were hammered out by local legislative actions.  Those new laws were jammed down the throats of the entrenced RR Engineers by the FRA over the objections of the RR Engineers complaints about the incorrectness of time keeping based on anything other than celestial observation.  An excellant example of practical application opposed to pure science!  Really, how accurate does 12:00 PM civil time need to co-inside with "Local Apparent Noon?"  It turns out that the answer is "a couple hours either way" is fine by the population as a whole given that it seldom changes when you walk to the next town (ahhh.. thusly the list of modern conveniences grows.)

 

Tiing it back.  Follow tradition.  jam UTC down the user's throats for logging!  It has saved lives before and it may prevent the death of the user you may otherwise strangle in the future!  Localization of displayed time is trivial  look on the community side for some examples from me.

 

Just for fun: Look up the "Gen. Mitchell Domes" in Milwaukee, Wisconsin.  Just outside you can read-up on all the math involved to generate simple instructions to follow to be a gnomon.


"Should be" isn't "Is" -Jay
0 Kudos
Message 23 of 24
(771 Views)

@JÞB wrote:

@drjdpowell wrote:

That system, which creates the files I'm reading, was written by very good programers with years of experience writing code for stuff you may use (or drive) every day. They don't just make stuff up or pretend. 


But they've not heard of UTC, Universal Standard Time?  Record the timezone offset of the data and correct for it.  Then you have the actual time to line things up with.  Local-time differences is a long-solved problem (older than computers I think; the railway engineers did it).


slightly OT but I'll tie it back to useful information.  

;

Sigh  "Local-time differences is a long-solved problem (older than computers I think; the railway engineers did it)."

Not really, the abacus could be considered a computer.  Worse, the way RR Engineers "Solved" local time differences was to add or subtract 4 minutes for each degree of longitude and publish the timetables in a manner that so confused the riders and workers that the safety of everyone was compromised.  A RR section worker would darned near need a sextant and a cloudless day along with his timetable to predict when the train would come along and kill all the people nearby if the signalman missread the timetable.  A totally "British" way to complicate things.  Luckilly, the American Vice president realized his residence (US Naval Observatory) actually had a functional component.  Timezones were adopted and adjustments between civil time and celestial observations were hammered out by local legislative actions.  Those new laws were jammed down the throats of the entrenced RR Engineers by the FRA over the objections of the RR Engineers complaints about the incorrectness of time keeping based on anything other than celestial observation.  An excellant example of practical application opposed to pure science!  Really, how accurate does 12:00 PM civil time need to co-inside with "Local Apparent Noon?"  It turns out that the answer is "a couple hours either way" is fine by the population as a whole given that it seldom changes when you walk to the next town (ahhh.. thusly the list of modern conveniences grows.)

 

Tiing it back.  Follow tradition.  jam UTC down the user's throats for logging!  It has saved lives before and it may prevent the death of the user you may otherwise strangle in the future!  Localization of displayed time is trivial  look on the community side for some examples from me.

 

Just for fun: Look up the "Gen. Mitchell Domes" in Milwaukee, Wisconsin.  Just outside you can read-up on all the math involved to generate simple instructions to follow to be a gnomon.


Sometimes you get a simple assignment and it gets all blown out of proportion.  The assignment was to graph some data, not rewrite the entire method of taking data.  A person whos task it is to grph data rarely has the clout to dictate changes of that magnitude.  (Although nothing is stopping said person to make a suggestion to the management!!!)

 

Don't get me wrong.  I'm all for exactly what you said.  I worked in the railroad industry, and all of the data streaming to the locomotive black box is UTC timestamped.  It's by far the easiest way to tell "exactly" when something happened.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 24 of 24
(756 Views)