Kind of puzzled about timestamps

[Bruce Labitt]

That was somewhat comical.  Yeah, been trying to keep everything with 
respect to UTC.  It can be a little difficult at times, as it's easy to 
goof up and fall in to quite a few time trap holes.

One of the more difficult things has been indexing into the time array.  
I've been using numpy's timedate64 and timedelta64 but occasionally 
still get tripped up. Handling time is complicated.  Fortunately, all 
that I care about for this project is relative time.  Start time, end 
time and time is "linear" in between.  According to the the youtuber, 
even that's not guaranteed if one spans the new year and we need a leap 
second!


On 3/4/21 10:51 PM, Joshua Judson Rosen wrote:
> See also: "The Problem with Time and Timezones" <https://www.youtube.com/watch?v=-5wpm-gesOY>
>
> 😣
>
> On 3/4/21 10:32 PM, Bruce Labitt wrote:
>> On 3/4/21 9:56 PM, Joshua Judson Rosen wrote:
>>> On 3/4/21 7:13 PM, Bruce Labitt wrote:
>>>> Good point.  I'll check that.  Logging machine was set to local time EST.  But it does have a wireless link, maybe it set itself internally to UT.  Thanks for the hint.
>>> You have your code explicitly calling a function named `UTC from timestamp'.
>>>
>>> If you want localtime and not UTC, call the function that doesn't start with "utc".
>>>
>>> And if you want to assume some particular timezone other than your system's default,
>>> you can pass that as an optional argument.
>>>
>>> BTW, FYI "UT" is *not* the same thing as "UTC". Timezones are confusing enough,
>>> it's worth spending the extra character to avoid creating even more confusion
>>> (or just call it "Z" and save yourself even more characters).
>>>
>>> And as a general word of advice from someone whose been burnt way too many times:
>>> if you're going to put timestamps in your filenames, either just use UTC
>>> or explicitly indicate which timezone the timestamps are assuming.
>>>
>>> "the local non-UTC timezone" *changes*. Frequently. Like, twice every year if you're lucky--
>>> and more frequently than that if you're unlucky. And if you are, for example, generating those
>>> files/filenames between 1:00 AM and 2:00 AM when you go from EDT to EST in November
>>> (and that "1:00-2:00 localtime" interval *repeats*)..., you'll be sorry.
>>>
>> These files are written by commercial closed box machines (medical
>> equipment).  There is no choice for the users.  That being said, these
>> machines are designed to basically have the time set once.  (Drift, ntp?
>> what's that?)  If one plays with resetting the time, one can be rewarded
>> by having all your data wiped.
>>
>> "UT" was me being lazy.  (Too lazy to type the extra character...)  I
>> don't have any code with explicit timezone stuff in it.  Have to agree
>> it's a good idea to keep time in UTC, to avoid 'many' of the headaches.
>> Nonetheless, it's easy to get confused about all this, especially if
>> external devices don't do time the same way.  (Not all devices handle
>> time correctly.) Then, as you say, you'll be sorry.
>