Re: Kind of puzzled about timestamps

[jonhall80]

I think that "time" is a bit like "taxes".   Everyone agrees life would be 
better if it was simpler, but people can not agree on how to do that, so we 
waste a lot of effort dealing with it.

md

On 03/10/2021 4:28 PM Ray Cote  wrote:

>  
>  
> No conversation about time is complete without a nod to 'Calendrical 
> Calculations' by Reingold and Dershowitz:  
> https://www.cambridge.org/us/academic/subjects/computer-science/computing-general-interest/calendrical-calculations-ultimate-edition-4th-edition?format=HB=9781107057623
>  
> I have three editions of this on my shelf. Everytime I think I have a 
> hard problem to solve I peruse a chapter and then realize my problems aren't 
> as difficult as time...
> --Ray
> 
> On Wed, Mar 10, 2021 at 12:51 PM Jerry Feldman < gaf.li...@gmail.com 
> mailto:gaf.li...@gmail.com > wrote:
> 
> > > Actually in was the Germans in 1916 that implemented it 
> first. Almost every other country adopted it shortly after, and we adopted it 
> in 1918.
> >  
> > IMHO: it made sense back then when the world was not universally 
> > electrified. It does not make sense in the 21st century. 
> > 
> > --
> > Jerry Feldman < gaf.li...@gmail.com mailto:gaf.li...@gmail.com >
> > Boston Linux and Unix http://www.blu.org
> > PGP key id: 6F6BB6E7
> > PGP Key fingerprint: 0EDC 2FF5 53A6 8EED 84D1  3050 5715 B88D 6F6
> > B B6E7
> > 
> > On Wed, Mar 10, 2021, 12:41 PM Tom Buskey < t...@buskey.name 
> > mailto:t...@buskey.name > wrote:
> > 
> > > > >  
> > > 
> > > On Mon, Mar 8, 2021 at 2:59 PM Curt Howland < 
> > > howl...@priss.com mailto:howl...@priss.com > wrote:
> > > 
> > > > > > > -BEGIN PGP SIGNED MESSAGE-
> > > > Hash: SHA256
> > > > 
> > > > On Monday 08 March 2021, Joshua Judson Rosen was heard 
> > > > to say:
> > > > > On 3/6/21 9:17 PM, Curt Howland wrote:
> > > > > > I mean, how silly can one be to object to it being 
> > > > dark when you
> > > > > > wake up, and then demanding that everyone else 
> > > > change the time on
> > > > > > their clocks so it's light at 7am the way you want 
> > > > it to be?
> > > > >
> > > > > Isn't that pretty much exactly the _opposite_ of what 
> > > > DST does?
> > > > 
> > > > Yes. That is given as a reason to change the clocks. 
> > > > Back during the
> > > > wave of "energy saving measures" in the early 1970s, 
> > > > staying on DST
> > > > through the year was objected to because, and I quote, 
> > > > "Children were
> > > > waiting for the bus in the dark."
> > > > 
> > > > 
> > > > > > >  
> > > And when they moved the dates by 3 weeks in 2007, they found 
> > > that the energy changes depended on your climate.  A study in California 
> > > found a 0.2% decrease in electricity.  A 2008 study in Indiana had a 1% 
> > > increase in consumption.
> > >  
> > > Of course that 1% in Indiana translated to ~ $9 million/yr.
> > >  
> > > FWIW, changing the clocks is not an American thing.  The UK 
> > > developed BST 1st.  So even the UK doesn't stay on GMT!
> > >  
> > > ___
> > > gnhlug-discuss mailing list
> > > gnhlug-discuss@mail.gnhlug.org 
> > > mailto:gnhlug-discuss@mail.gnhlug.org
> > > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
> > > 
> > > > > ___
> > gnhlug-discuss mailing list
> > gnhlug-discuss@mail.gnhlug.org mailto:gnhlug-discuss@mail.gnhlug.org
> > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
> > 
> > > 
>  
> --
> Raymond Cote, CTO
> voice: +1.603.924.6079 email: rgac...@appropriatesolutions.com skype: 
> ray.cote
> Schedule a meeting: https://calendly.com/ray_cote/60min/
>  
>  
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
> 
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Ray Cote]

No conversation about time is complete without a nod to 'Calendrical
Calculations' by Reingold and Dershowitz:
https://www.cambridge.org/us/academic/subjects/computer-science/computing-general-interest/calendrical-calculations-ultimate-edition-4th-edition?format=HB=9781107057623

I have three editions of this on my shelf. Everytime I think I have a hard
problem to solve I peruse a chapter and then realize my problems aren't as
difficult as time...
--Ray

On Wed, Mar 10, 2021 at 12:51 PM Jerry Feldman  wrote:

> Actually in was the Germans in 1916 that implemented it first. Almost
> every other country adopted it shortly after, and we adopted it in 1918.
>
> IMHO: it made sense back then when the world was not universally
> electrified. It does not make sense in the 21st century.
>
> --
> Jerry Feldman 
> Boston Linux and Unix http://www.blu.org
> PGP key id: 6F6BB6E7
> PGP Key fingerprint: 0EDC 2FF5 53A6 8EED 84D1  3050 5715 B88D 6F6
> B B6E7
>
> On Wed, Mar 10, 2021, 12:41 PM Tom Buskey  wrote:
>
>>
>>
>> On Mon, Mar 8, 2021 at 2:59 PM Curt Howland  wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> On Monday 08 March 2021, Joshua Judson Rosen was heard to say:
>>> > On 3/6/21 9:17 PM, Curt Howland wrote:
>>> > > I mean, how silly can one be to object to it being dark when you
>>> > > wake up, and then demanding that everyone else change the time on
>>> > > their clocks so it's light at 7am the way you want it to be?
>>> >
>>> > Isn't that pretty much exactly the _opposite_ of what DST does?
>>>
>>> Yes. That is given as a reason to change the clocks. Back during the
>>> wave of "energy saving measures" in the early 1970s, staying on DST
>>> through the year was objected to because, and I quote, "Children were
>>> waiting for the bus in the dark."
>>>
>>>
>> And when they moved the dates by 3 weeks in 2007, they found that the
>> energy changes depended on your climate.  A study in California found a
>> 0.2% decrease in electricity.  A 2008 study in Indiana had a 1% increase in
>> consumption.
>>
>> Of course that 1% in Indiana translated to ~ $9 million/yr.
>>
>> FWIW, changing the clocks is not an American thing.  The UK developed BST
>> 1st.  So even the UK doesn't stay on GMT!
>>
>> ___
>> gnhlug-discuss mailing list
>> gnhlug-discuss@mail.gnhlug.org
>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>


-- 
Raymond Cote, CTO
voice: +1.603.924.6079 email: rgac...@appropriatesolutions.com skype:
ray.cote
Schedule a meeting: https://calendly.com/ray_cote/60min/
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Jerry Feldman]

Actually in was the Germans in 1916 that implemented it first. Almost every
other country adopted it shortly after, and we adopted it in 1918.

IMHO: it made sense back then when the world was not universally
electrified. It does not make sense in the 21st century.

--
Jerry Feldman 
Boston Linux and Unix http://www.blu.org
PGP key id: 6F6BB6E7
PGP Key fingerprint: 0EDC 2FF5 53A6 8EED 84D1  3050 5715 B88D 6F6
B B6E7

On Wed, Mar 10, 2021, 12:41 PM Tom Buskey  wrote:

>
>
> On Mon, Mar 8, 2021 at 2:59 PM Curt Howland  wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On Monday 08 March 2021, Joshua Judson Rosen was heard to say:
>> > On 3/6/21 9:17 PM, Curt Howland wrote:
>> > > I mean, how silly can one be to object to it being dark when you
>> > > wake up, and then demanding that everyone else change the time on
>> > > their clocks so it's light at 7am the way you want it to be?
>> >
>> > Isn't that pretty much exactly the _opposite_ of what DST does?
>>
>> Yes. That is given as a reason to change the clocks. Back during the
>> wave of "energy saving measures" in the early 1970s, staying on DST
>> through the year was objected to because, and I quote, "Children were
>> waiting for the bus in the dark."
>>
>>
> And when they moved the dates by 3 weeks in 2007, they found that the
> energy changes depended on your climate.  A study in California found a
> 0.2% decrease in electricity.  A 2008 study in Indiana had a 1% increase in
> consumption.
>
> Of course that 1% in Indiana translated to ~ $9 million/yr.
>
> FWIW, changing the clocks is not an American thing.  The UK developed BST
> 1st.  So even the UK doesn't stay on GMT!
>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Tom Buskey]

On Mon, Mar 8, 2021 at 2:59 PM Curt Howland  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Monday 08 March 2021, Joshua Judson Rosen was heard to say:
> > On 3/6/21 9:17 PM, Curt Howland wrote:
> > > I mean, how silly can one be to object to it being dark when you
> > > wake up, and then demanding that everyone else change the time on
> > > their clocks so it's light at 7am the way you want it to be?
> >
> > Isn't that pretty much exactly the _opposite_ of what DST does?
>
> Yes. That is given as a reason to change the clocks. Back during the
> wave of "energy saving measures" in the early 1970s, staying on DST
> through the year was objected to because, and I quote, "Children were
> waiting for the bus in the dark."
>
>
And when they moved the dates by 3 weeks in 2007, they found that the
energy changes depended on your climate.  A study in California found a
0.2% decrease in electricity.  A 2008 study in Indiana had a 1% increase in
consumption.

Of course that 1% in Indiana translated to ~ $9 million/yr.

FWIW, changing the clocks is not an American thing.  The UK developed BST
1st.  So even the UK doesn't stay on GMT!
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Jerry Feldman]

He needed a calendar watch. All of us Viet Nam veterans had Seiko watches 

--
Jerry Feldman 
Boston Linux and Unix http://www.blu.org
PGP key id: 6F6BB6E7
PGP Key fingerprint: 0EDC 2FF5 53A6 8EED 84D1  3050 5715 B88D 6F6
B B6E7

On Mon, Mar 8, 2021, 9:33 PM  wrote:

> It was 1974 and the IBM 360 had an unsigned 64 bit clock that updated (I
> believe) every ten milliseconds.
>
> The operator booted the online transactional system and mistakenly typed
> in the next day's date.   They IMMEDIATELY realized the error, shut the
> machine down and brought it up again typing in the right datebut it was
> too late.
>
> *One* transaction had been entered into the system on the "next day".
>
> After the math was done that ONE transaction offset 400,000 other
> transactions that day that would normally have an average calculated value
> of being two to three days in the system to create an AVERAGE "in system"
> transaction time of three or four hundred years (I can not remember exactly
> what we calculated).
>
> Our reports could not even print out the number, it was too large for the
> field.
>
> md
> > On 03/08/2021 7:45 PM r...@mrt4.com wrote:
> >
> >
> > Here's my story about time...
> >
> > I had an old computer I was using as an email server and I just
> configured the time to sync once a day, which seemed often enough for
> email. The clock started to go bad, drifting several minutes a day (I don't
> remember now if it was forward or backward because I'm getting pretty old
> myself), and when it resynced each day, well, I couldn't understand why my
> logs kept indicating that the system was violating causality...
> >
> > > You could plan a vacation in Switzerland in 2030, but if an asteroid
> > > obliterates Switzerland in 2028, your vacation plans become null and
> void.
> > > It's not a contingency you need to plan for when making your vacation
> > > plans.
> > >
> >
> > Depends on the size of the asteroid. (apocalypse humor)
> >
> > Ronald
> > r...@mrt4.com
> > ___
> > gnhlug-discuss mailing list
> > gnhlug-discuss@mail.gnhlug.org
> > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[jonhall80]

It was 1974 and the IBM 360 had an unsigned 64 bit clock that updated (I 
believe) every ten milliseconds.

The operator booted the online transactional system and mistakenly typed in the 
next day's date.   They IMMEDIATELY realized the error, shut the machine down 
and brought it up again typing in the right datebut it was too late.

*One* transaction had been entered into the system on the "next day".

After the math was done that ONE transaction offset 400,000 other transactions 
that day that would normally have an average calculated value of being two to 
three days in the system to create an AVERAGE "in system" transaction time of 
three or four hundred years (I can not remember exactly what we calculated).

Our reports could not even print out the number, it was too large for the field.

md
> On 03/08/2021 7:45 PM r...@mrt4.com wrote:
> 
>  
> Here's my story about time...
> 
> I had an old computer I was using as an email server and I just configured 
> the time to sync once a day, which seemed often enough for email. The clock 
> started to go bad, drifting several minutes a day (I don't remember now if it 
> was forward or backward because I'm getting pretty old myself), and when it 
> resynced each day, well, I couldn't understand why my logs kept indicating 
> that the system was violating causality...
> 
> > You could plan a vacation in Switzerland in 2030, but if an asteroid
> > obliterates Switzerland in 2028, your vacation plans become null and void.
> > It's not a contingency you need to plan for when making your vacation
> > plans.
> > 
> 
> Depends on the size of the asteroid. (apocalypse humor)
> 
> Ronald
> r...@mrt4.com
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Jerry Feldman]

128 bits 

--
Jerry Feldman 
Boston Linux and Unix http://www.blu.org
PGP key id: 6F6BB6E7
PGP Key fingerprint: 0EDC 2FF5 53A6 8EED 84D1  3050 5715 B88D 6F6
B B6E7

On Mon, Mar 8, 2021, 6:21 PM Curt Howland  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Monday 08 March 2021, Joshua Judson Rosen was heard to say:
> >   What's the likelihood that this date is going to pass through a
> > computer where time_t is not wider than 32 bits before then?
>
> Hehehehe.
>
> Tovalds was asked about the 2038 problem would be a problem. From
> memory, he said, "It's nothing more difficult than changing the
> counter from 32 bits to 64 bits, and a recompile. I hope people are
> using something better than Linux by then."
>
>
> - --
> You may my glories and my state dispose,
> But not my griefs; still am I king of those.
>  --- William Shakespeare, "Richard II"
>
> -BEGIN PGP SIGNATURE-
>
> iHUEAREIAB0WIQTaYVhJsIalt8scIDa2T1fo1pHhqQUCYEaxTwAKCRC2T1fo1pHh
> qVMAAP9a5zgkthHz+iwg4p6jaxZl8gqLcmcWns1bv6F/h+ncQAD+Kl5CiRLPSIE9
> DvCrglbqU+DSLsRyhqAJF8YII2cpkik=
> =4Xor
> -END PGP SIGNATURE-
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Bruce Labitt]

Yet you might think that since many, many people pay off mortgages or pay
off mortgages on sales of property every single year that they might have
it down to a science by now.   It is not like I am the first mortgage that
has been paid off in the past 30 years..

Maddog, I totally agree with you.  I was astonished and more than a little
annoyed that it took so long.  You'd think it was the first time (every
time!).  Apparently the banks aren't too innovative in this respect...
-Bruce

On Mon, Mar 8, 2021 at 7:45 PM  wrote:

> Here's my story about time...
>
> I had an old computer I was using as an email server and I just configured
> the time to sync once a day, which seemed often enough for email. The clock
> started to go bad, drifting several minutes a day (I don't remember now if
> it was forward or backward because I'm getting pretty old myself), and when
> it resynced each day, well, I couldn't understand why my logs kept
> indicating that the system was violating causality...
>
> > You could plan a vacation in Switzerland in 2030, but if an asteroid
> > obliterates Switzerland in 2028, your vacation plans become null and
> void.
> > It's not a contingency you need to plan for when making your vacation
> > plans.
> >
>
> Depends on the size of the asteroid. (apocalypse humor)
>
> Ronald
> r...@mrt4.com
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[r270]

Here's my story about time...

I had an old computer I was using as an email server and I just configured the 
time to sync once a day, which seemed often enough for email. The clock started 
to go bad, drifting several minutes a day (I don't remember now if it was 
forward or backward because I'm getting pretty old myself), and when it 
resynced each day, well, I couldn't understand why my logs kept indicating that 
the system was violating causality...

> You could plan a vacation in Switzerland in 2030, but if an asteroid
> obliterates Switzerland in 2028, your vacation plans become null and void.
> It's not a contingency you need to plan for when making your vacation
> plans.
> 

Depends on the size of the asteroid. (apocalypse humor)

Ronald
r...@mrt4.com
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[jonhall80]

Bruce,

Yes, you are probably right.   I know enough how banks bundle up mortgages, to 
agree that might be part of the problem.

Yet you might think that since many, many people pay off mortgages or pay off 
mortgages on sales of property every single year that they might have it down 
to a science by now.   It is not like I am the first mortgage than has been 
paid off in the past 30 years..

>From my viewpoint the person at the bank should just push the button on the 
>desk and get a diet coke delivered to them..oh, waitthat is someone 
>else.

> On 03/08/2021 7:03 PM Bruce Labitt  wrote:
>  
>  
> If my experience is a guide, you have a few more months to go.  Once we 
> paid off our mortgage it took almost 6 months to clear everything up.  (That 
> was in late 2018)  What you probably aren't realizing is that they have to 
> hunt down your paperwork.  Your note was probably transferred to dozens of 
> investors who bought and sold paper.  They are tracking it down by going 
> through the chain of possession.  The days of your bank holding your mortgage 
> papers in the local vault are gone forever.  
>  
> But yeah, late a day, they'd call you...  
> 
> On Mon, Mar 8, 2021 at 6:21 PM < jonhal...@comcast.net 
> mailto:jonhal...@comcast.net > wrote:
> 
> > > I paid off my 30 year mortgage on November 29th, 2020 (two years 
> early) thinking that it would be better not to carry any of it over to the 
> next year.
> > 
> > Then I waited for all of the associated paperwork (escrow payment 
> > refunds for property tax, deed, etc.)  At the end of January I called the 
> > bank.
> > 
> > "Oh yes, it appears you have paid it off.   Well, it takes a little 
> > time."
> > 
> > Then the end of February I called again.
> > 
> > "Oh, yes, we can see the zero principal back in Decemberyes, 
> > you are right...any day now"
> > 
> > Here it is, March 8th, 2021.
> > 
> > If I was two days late on a payment, they hounded me.
> > 
> > They are not using a computer.   They are using quill pens and 
> > parchment.
> > 
> > md
> > > On 03/08/2021 4:08 PM Joshua Judson Rosen < 
> > roz...@hackerposse.com mailto:roz...@hackerposse.com > wrote:
> > >
> > > 
> > > On 3/8/21 2:16 PM, Jerry Feldman wrote:
> > > > I love this discussion. I've been involved with computer time 
> > since the early 1970s. While at burger King I wrote a standardized set of 
> > time utilities in cobol. Later at Digital I was responsible for the utmp 
> > libraries, and the standard test failed. The issue was that the
> > > > standard test used a future time beyond 2035. Back then tine_t 
> > was a signed 32 bit integer
> > >
> > > I bought a house with a 30-year mortgage in late 2008. My first 
> > house, actually.
> > >
> > > All of the things that people talk about being afraid of with 
> > being a new home-buyer...,
> > > well..., none of them compared to the sense of dread that I felt 
> > when I looked at
> > > the end-date on the mortgage and asked myself:
> > >
> > >   What's the likelihood that this date is going to pass 
> > through a computer
> > >   where time_t is not wider than 32 bits before then?
> > >
> > > So I pay a little extra each month.
> > > Hopefully I can have the account closed and expunged before that 
> > point ;p
> > >
> > > --
> > > Connect with me on the GNU social network: < 
> > https://status.hackerposse.com/rozzin>
> > > Not on the network? Ask me for an invitation to a social hub!
> > > ___
> > > gnhlug-discuss mailing list
> > > gnhlug-discuss@mail.gnhlug.org 
> > mailto:gnhlug-discuss@mail.gnhlug.org
> > > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
> > ___
> > gnhlug-discuss mailing list
> > gnhlug-discuss@mail.gnhlug.org mailto:gnhlug-discuss@mail.gnhlug.org
> > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
> > 
> > > 
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Bruce Labitt]

If my experience is a guide, you have a few more months to go.  Once we
paid off our mortgage it took almost 6 months to clear everything up.
(That was in late 2018)  What you probably aren't realizing is that they
have to hunt down your paperwork.  Your note was probably transferred to
dozens of investors who bought and sold paper.  They are tracking it down
by going through the chain of possession.  The days of your bank holding
your mortgage papers in the local vault are gone forever.

But yeah, late a day, they'd call you...

On Mon, Mar 8, 2021 at 6:21 PM  wrote:

> I paid off my 30 year mortgage on November 29th, 2020 (two years early)
> thinking that it would be better not to carry any of it over to the next
> year.
>
> Then I waited for all of the associated paperwork (escrow payment refunds
> for property tax, deed, etc.)  At the end of January I called the bank.
>
> "Oh yes, it appears you have paid it off.   Well, it takes a little time."
>
> Then the end of February I called again.
>
> "Oh, yes, we can see the zero principal back in Decemberyes, you are
> right...any day now"
>
> Here it is, March 8th, 2021.
>
> If I was two days late on a payment, they hounded me.
>
> They are not using a computer.   They are using quill pens and parchment.
>
> md
> > On 03/08/2021 4:08 PM Joshua Judson Rosen 
> wrote:
> >
> >
> > On 3/8/21 2:16 PM, Jerry Feldman wrote:
> > > I love this discussion. I've been involved with computer time since
> the early 1970s. While at burger King I wrote a standardized set of time
> utilities in cobol. Later at Digital I was responsible for the utmp
> libraries, and the standard test failed. The issue was that the
> > > standard test used a future time beyond 2035. Back then tine_t was a
> signed 32 bit integer
> >
> > I bought a house with a 30-year mortgage in late 2008. My first house,
> actually.
> >
> > All of the things that people talk about being afraid of with being a
> new home-buyer...,
> > well..., none of them compared to the sense of dread that I felt when I
> looked at
> > the end-date on the mortgage and asked myself:
> >
> >   What's the likelihood that this date is going to pass through a
> computer
> >   where time_t is not wider than 32 bits before then?
> >
> > So I pay a little extra each month.
> > Hopefully I can have the account closed and expunged before that point ;p
> >
> > --
> > Connect with me on the GNU social network: <
> https://status.hackerposse.com/rozzin>
> > Not on the network? Ask me for an invitation to a social hub!
> > ___
> > gnhlug-discuss mailing list
> > gnhlug-discuss@mail.gnhlug.org
> > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Curt Howland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Monday 08 March 2021, Joshua Judson Rosen was heard to say:
>   What's the likelihood that this date is going to pass through a
> computer where time_t is not wider than 32 bits before then?

Hehehehe.

Tovalds was asked about the 2038 problem would be a problem. From 
memory, he said, "It's nothing more difficult than changing the 
counter from 32 bits to 64 bits, and a recompile. I hope people are 
using something better than Linux by then."


- -- 
You may my glories and my state dispose,
But not my griefs; still am I king of those.
 --- William Shakespeare, "Richard II"

-BEGIN PGP SIGNATURE-

iHUEAREIAB0WIQTaYVhJsIalt8scIDa2T1fo1pHhqQUCYEaxTwAKCRC2T1fo1pHh
qVMAAP9a5zgkthHz+iwg4p6jaxZl8gqLcmcWns1bv6F/h+ncQAD+Kl5CiRLPSIE9
DvCrglbqU+DSLsRyhqAJF8YII2cpkik=
=4Xor
-END PGP SIGNATURE-
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[jonhall80]

I paid off my 30 year mortgage on November 29th, 2020 (two years early) 
thinking that it would be better not to carry any of it over to the next year.

Then I waited for all of the associated paperwork (escrow payment refunds for 
property tax, deed, etc.)  At the end of January I called the bank.

"Oh yes, it appears you have paid it off.   Well, it takes a little time."

Then the end of February I called again.

"Oh, yes, we can see the zero principal back in Decemberyes, you are 
right...any day now"

Here it is, March 8th, 2021.

If I was two days late on a payment, they hounded me.

They are not using a computer.   They are using quill pens and parchment.

md
> On 03/08/2021 4:08 PM Joshua Judson Rosen  wrote:
> 
>  
> On 3/8/21 2:16 PM, Jerry Feldman wrote:
> > I love this discussion. I've been involved with computer time since the 
> > early 1970s. While at burger King I wrote a standardized set of time 
> > utilities in cobol. Later at Digital I was responsible for the utmp 
> > libraries, and the standard test failed. The issue was that the 
> > standard test used a future time beyond 2035. Back then tine_t was a signed 
> > 32 bit integer
> 
> I bought a house with a 30-year mortgage in late 2008. My first house, 
> actually.
> 
> All of the things that people talk about being afraid of with being a new 
> home-buyer...,
> well..., none of them compared to the sense of dread that I felt when I 
> looked at
> the end-date on the mortgage and asked myself:
> 
>   What's the likelihood that this date is going to pass through a computer
>   where time_t is not wider than 32 bits before then?
> 
> So I pay a little extra each month.
> Hopefully I can have the account closed and expunged before that point ;p
> 
> -- 
> Connect with me on the GNU social network: 
> 
> Not on the network? Ask me for an invitation to a social hub!
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Jerry Feldman]

 Banks and other financial institutions have long used math packages that
made 2035 moot. Loans and risk computations frequently go 50 years or
longer. I worked for algorithmics for 10 years. We had a C++ customized
package.

--
Jerry Feldman 
Boston Linux and Unix http://www.blu.org
PGP key id: 6F6BB6E7
PGP Key fingerprint: 0EDC 2FF5 53A6 8EED 84D1  3050 5715 B88D 6F6
B B6E7

On Mon, Mar 8, 2021, 4:09 PM Joshua Judson Rosen 
wrote:

> On 3/8/21 2:16 PM, Jerry Feldman wrote:
> > I love this discussion. I've been involved with computer time since the
> early 1970s. While at burger King I wrote a standardized set of time
> utilities in cobol. Later at Digital I was responsible for the utmp
> libraries, and the standard test failed. The issue was that the
> > standard test used a future time beyond 2035. Back then tine_t was a
> signed 32 bit integer
>
> I bought a house with a 30-year mortgage in late 2008. My first house,
> actually.
>
> All of the things that people talk about being afraid of with being a new
> home-buyer...,
> well..., none of them compared to the sense of dread that I felt when I
> looked at
> the end-date on the mortgage and asked myself:
>
> What's the likelihood that this date is going to pass through a
> computer
> where time_t is not wider than 32 bits before then?
>
> So I pay a little extra each month.
> Hopefully I can have the account closed and expunged before that point ;p
>
> --
> Connect with me on the GNU social network: <
> https://status.hackerposse.com/rozzin>
> Not on the network? Ask me for an invitation to a social hub!
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Joshua Judson Rosen]

On 3/8/21 2:16 PM, Jerry Feldman wrote:
> I love this discussion. I've been involved with computer time since the early 
> 1970s. While at burger King I wrote a standardized set of time utilities in 
> cobol. Later at Digital I was responsible for the utmp libraries, and the 
> standard test failed. The issue was that the 
> standard test used a future time beyond 2035. Back then tine_t was a signed 
> 32 bit integer

I bought a house with a 30-year mortgage in late 2008. My first house, actually.

All of the things that people talk about being afraid of with being a new 
home-buyer...,
well..., none of them compared to the sense of dread that I felt when I looked 
at
the end-date on the mortgage and asked myself:

What's the likelihood that this date is going to pass through a computer
where time_t is not wider than 32 bits before then?

So I pay a little extra each month.
Hopefully I can have the account closed and expunged before that point ;p

-- 
Connect with me on the GNU social network: 

Not on the network? Ask me for an invitation to a social hub!
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Jerry Feldman]

In 2005 bush extended DST to the current dates, but we had DST for many
years before that.

--
Jerry Feldman 
Boston Linux and Unix http://www.blu.org
PGP key id: 6F6BB6E7
PGP Key fingerprint: 0EDC 2FF5 53A6 8EED 84D1  3050 5715 B88D 6F6
B B6E7

On Mon, Mar 8, 2021, 2:59 PM Curt Howland  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Monday 08 March 2021, Joshua Judson Rosen was heard to say:
> > On 3/6/21 9:17 PM, Curt Howland wrote:
> > > I mean, how silly can one be to object to it being dark when you
> > > wake up, and then demanding that everyone else change the time on
> > > their clocks so it's light at 7am the way you want it to be?
> >
> > Isn't that pretty much exactly the _opposite_ of what DST does?
>
> Yes. That is given as a reason to change the clocks. Back during the
> wave of "energy saving measures" in the early 1970s, staying on DST
> through the year was objected to because, and I quote, "Children were
> waiting for the bus in the dark."
>
> It was utterly inconceivable to start school later, to adapt to local
> conditions. No, everyone _else_ had to be changed.
>
> > And I guess
> > by the time *spring* rolls in they've forgot that `winter' even was
> > ever a thing
>
> Just like everyone forgets how to drive in snow over the summer.
>
> - --
> You may my glories and my state dispose,
> But not my griefs; still am I king of those.
>  --- William Shakespeare, "Richard II"
>
> -BEGIN PGP SIGNATURE-
>
> iHUEAREIAB0WIQTaYVhJsIalt8scIDa2T1fo1pHhqQUCYEaCCwAKCRC2T1fo1pHh
> qcBWAP9tjJK6fbagBRBeWEaLIEEGMAzkIwAzOwwUi+Yz2jev+AD/WXBR34aXTXvq
> Vh4G+HQLPH4F5qdH3Q3ZB1hDPWPMseQ=
> =AYrj
> -END PGP SIGNATURE-
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Curt Howland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Monday 08 March 2021, Joshua Judson Rosen was heard to say:
> On 3/6/21 9:17 PM, Curt Howland wrote:
> > I mean, how silly can one be to object to it being dark when you
> > wake up, and then demanding that everyone else change the time on
> > their clocks so it's light at 7am the way you want it to be?
>
> Isn't that pretty much exactly the _opposite_ of what DST does?

Yes. That is given as a reason to change the clocks. Back during the 
wave of "energy saving measures" in the early 1970s, staying on DST 
through the year was objected to because, and I quote, "Children were 
waiting for the bus in the dark."

It was utterly inconceivable to start school later, to adapt to local 
conditions. No, everyone _else_ had to be changed.

> And I guess 
> by the time *spring* rolls in they've forgot that `winter' even was
> ever a thing

Just like everyone forgets how to drive in snow over the summer.

- -- 
You may my glories and my state dispose,
But not my griefs; still am I king of those.
 --- William Shakespeare, "Richard II"

-BEGIN PGP SIGNATURE-

iHUEAREIAB0WIQTaYVhJsIalt8scIDa2T1fo1pHhqQUCYEaCCwAKCRC2T1fo1pHh
qcBWAP9tjJK6fbagBRBeWEaLIEEGMAzkIwAzOwwUi+Yz2jev+AD/WXBR34aXTXvq
Vh4G+HQLPH4F5qdH3Q3ZB1hDPWPMseQ=
=AYrj
-END PGP SIGNATURE-
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Jerry Feldman]

I think DST has outlived its usefulness. There was a proposal to move MA to
the Atlantic Time Zone. There was a more recent proposal for CT to move,
but it makes no sense without NH and ME. I think stability is more
important.

--
Jerry Feldman 
Boston Linux and Unix http://www.blu.org
PGP key id: 6F6BB6E7
PGP Key fingerprint: 0EDC 2FF5 53A6 8EED 84D1  3050 5715 B88D 6F6
B B6E7

On Mon, Mar 8, 2021, 2:44 PM Joshua Judson Rosen 
wrote:

> On 3/6/21 9:17 PM, Curt Howland wrote:
> > On Saturday 06 March 2021, Ben Scott was heard to say:
> >> Even that's not enough, because the stupid humans keep changing
> >> what the time zones mean.
> >
> > With GMT as the standard time stamp, one can at least know relative
> > times of files, even if one does not know such real-world details.
> >
> > I've gotten into a couple of heated arguments for/against the idea of
> > using GMT for everything, and then adapting what time things happen
> > to local conditions. The reactions to that idea have been
> > fascinating. Much like the arguments about Daylight Saving.
> >
> > I mean, how silly can one be to object to it being dark when you wake
> > up, and then demanding that everyone else change the time on their
> > clocks so it's light at 7am the way you want it to be?
>
> Isn't that pretty much exactly the _opposite_ of what DST does?
>
> Every Spring, I get delighted that the sun is finally rising early enough
> to make it easy to get up at what's supposed to be `a reasonable time' in
> the morning,
> and I then DST comes in and makes the sun not rise for another hour.
> Ha-ha! Early April Fools'! Another month of dark mornings!
>
> And then all of the news channels are flooded with people opining about
> how much `better' it would be `if we just had DST all year' because
> all they care about is having daylight-fun hours at the _tail end of the
> day_,
> because..., I don't know--they're all unemployed? Or by the end of the day
> they've forgotten how hard it was to get out of the bed and be useful
> that morning? And I guess by the time *spring* rolls in they've forgot
> that `winter' even was ever a thing
>
> --
> Connect with me on the GNU social network: <
> https://status.hackerposse.com/rozzin>
> Not on the network? Ask me for an invitation to a social hub!
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Joshua Judson Rosen]

On 3/6/21 9:17 PM, Curt Howland wrote:
> On Saturday 06 March 2021, Ben Scott was heard to say:
>> Even that's not enough, because the stupid humans keep changing
>> what the time zones mean.
> 
> With GMT as the standard time stamp, one can at least know relative
> times of files, even if one does not know such real-world details.
> 
> I've gotten into a couple of heated arguments for/against the idea of
> using GMT for everything, and then adapting what time things happen
> to local conditions. The reactions to that idea have been
> fascinating. Much like the arguments about Daylight Saving.
> 
> I mean, how silly can one be to object to it being dark when you wake
> up, and then demanding that everyone else change the time on their
> clocks so it's light at 7am the way you want it to be?

Isn't that pretty much exactly the _opposite_ of what DST does?

Every Spring, I get delighted that the sun is finally rising early enough
to make it easy to get up at what's supposed to be `a reasonable time' in the 
morning,
and I then DST comes in and makes the sun not rise for another hour.
Ha-ha! Early April Fools'! Another month of dark mornings!

And then all of the news channels are flooded with people opining about
how much `better' it would be `if we just had DST all year' because
all they care about is having daylight-fun hours at the _tail end of the day_,
because..., I don't know--they're all unemployed? Or by the end of the day
they've forgotten how hard it was to get out of the bed and be useful
that morning? And I guess by the time *spring* rolls in they've forgot
that `winter' even was ever a thing

-- 
Connect with me on the GNU social network: 

Not on the network? Ask me for an invitation to a social hub!
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Jerry Feldman]

I love this discussion. I've been involved with computer time since the
early 1970s. While at burger King I wrote a standardized set of time
utilities in cobol. Later at Digital I was responsible for the utmp
libraries, and the standard test failed. The issue was that the standard
test used a future time beyond 2035. Back then tine_t was a signed 32 bit
integer

--
Jerry Feldman 
Boston Linux and Unix http://www.blu.org
PGP key id: 6F6BB6E7
PGP Key fingerprint: 0EDC 2FF5 53A6 8EED 84D1  3050 5715 B88D 6F6
B B6E7

On Mon, Mar 8, 2021, 2:00 PM Joshua Judson Rosen 
wrote:

> On 3/6/21 7:46 PM, Ben Scott wrote:
> > On Thu, Mar 4, 2021 at 9:57 PM Joshua Judson Rosen
> >  wrote:
> >> 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.
> >
> > Even that's not enough, because the stupid humans keep changing what
> > the time zones mean.  Say you find a file that has a stored time of
> > 2007 MAR 31 17:00 UTC.  If that file was written before 2005, then the
> > offset to US Eastern is 5 hours.  If that file was written after 2005,
> > the offset is 4 hours.  Which did the human mean when they instructed
> > the computer to write the file?  No way of knowing, in the general
> > case.
>
> Well..., I _did_ say "either... or...". The general idea is just `don't
> assume
> that the reader will just know what scale/units you're using without it
> being declared'.
>
> But some things that I really neglected to mention were:
>
> 1) that "indicate which timezone" is itself actually multiple
> different approaches:
>hours offset from UTC, or the _symbolic_ timezone that
> automatically adjusts
>to changing politics.
> 2) if you want to use those stamps to actually _convey
> information_, then
>which one of _those_ you need depends on specifically what
> you're doing:
>sometimes you want to indicate an actual point on the general
> timeline,
>sometimes you want to indicate how something fits into the
> local schedule
>or relates to `solar time' (e.g.: as a _nerd_, I thought it'd
> be a great idea
>to set my digital cameras' clocks to UTC and just never deal
> with DST or
>any other timezone issues when traveling..., and then as a
> _photographer_ I realized
>what a lousy idea that could end up being...).
> 3) sometimes you need to indicate _both_
> 4) you might even need to give your symbolic timezone, your
> timezone offset, _and_ UTC..., _and_
>
> ... BUT: even if you only do any arbitrary one of those things, at least
> you won't end up
> mistakenly overwriting your records due to multiple distinct points in time
> end up generating the same filename.
>
> (the inverse issue, of whether you end up mistakenly _failing to generate
> collisions when you want to_
>   can also be a concern of course; but I'd rather leave that as an
> exercise to the reader..., or to Ben ;p)
>
> I *also* didn't even touch on how much all of this will annoy people who
> like nicely-sorting filenames... ;p
>
> Every once in a while, I go back to try to find a solution to all of the
> other problems that also
> fits in with _that_, and just fail. Basically..., whenever anyone asks me
> "what time is it?".
> And I think I've been at that for 10 years now
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Joshua Judson Rosen]

On 3/8/21 7:28 AM, John Abreau wrote:
> 
> 
> On Sat, Mar 6, 2021 at 7:48 PM Ben Scott  > wrote:
> 
> On Thu, Mar 4, 2021 at 9:57 PM Joshua Judson Rosen
> mailto:roz...@hackerposse.com>> wrote:
>  > 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.
> 
> Even that's not enough, because the stupid humans keep changing what
> the time zones mean.  Say you find a file that has a stored time of
> 2007 MAR 31 17:00 UTC.  If that file was written before 2005, then the
> offset to US Eastern is 5 hours.  If that file was written after 2005,
> the offset is 4 hours.  Which did the human mean when they instructed
> the computer to write the file?  No way of knowing, in the general
> case.
> 
> 
> I'd argue that this case does not matter, because the human is making a 
> reference to an event in the future, and it is impossible in principle to 
> anticipate unexpected future changes in such definitions.
> 
> You could plan a vacation in Switzerland in 2030, but if an asteroid 
> obliterates Switzerland in 2028, your vacation plans become null and void. 
> It's not a contingency you need to plan for when making your vacation plans.
Next: Opening the software toolbox,  Prev: File timestamps,  Up: Top

29 Date input formats
*

First, a quote:

  Our units of temporal measurement, from seconds on up to months,
  are so complicated, asymmetrical and disjunctive so as to make
  coherent mental reckoning in time all but impossible.  Indeed, had
  some tyrannical god contrived to enslave our minds to time, to make
  it all but impossible for us to escape subjection to sodden
  routines and unpleasant surprises, he could hardly have done better
  than handing down our present system.  It is like a set of
  trapezoidal building blocks, with no vertical or horizontal
  surfaces, like a language in which the simplest thought demands
  ornate constructions, useless particles and lengthy
  circumlocutions.  Unlike the more successful patterns of language
  and science, which enable us to face experience boldly or at least
  level-headedly, our system of temporal calculation silently and
  persistently encourages our terror of time.

  ... It is as though architects had to measure length in feet, width
  in meters and height in ells; as though basic instruction manuals
  demanded a knowledge of five different languages.  It is no wonder
  then that we often look into our own immediate past or future, last
  Tuesday or a week from Sunday, with feelings of helpless confusion.
  ...

  —Robert Grudin, ‘Time and the Art of Living’.

-Info: (coreutils)Date input formats, 50 lines --Top


-- 
Connect with me on the GNU social network: 

Not on the network? Ask me for an invitation to a social hub!
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Joshua Judson Rosen]

On 3/6/21 7:46 PM, Ben Scott wrote:
> On Thu, Mar 4, 2021 at 9:57 PM Joshua Judson Rosen
>  wrote:
>> 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.
> 
> Even that's not enough, because the stupid humans keep changing what
> the time zones mean.  Say you find a file that has a stored time of
> 2007 MAR 31 17:00 UTC.  If that file was written before 2005, then the
> offset to US Eastern is 5 hours.  If that file was written after 2005,
> the offset is 4 hours.  Which did the human mean when they instructed
> the computer to write the file?  No way of knowing, in the general
> case.

Well..., I _did_ say "either... or...". The general idea is just `don't assume
that the reader will just know what scale/units you're using without it being 
declared'.

But some things that I really neglected to mention were:

1) that "indicate which timezone" is itself actually multiple different 
approaches:
   hours offset from UTC, or the _symbolic_ timezone that automatically 
adjusts
   to changing politics.
2) if you want to use those stamps to actually _convey information_, 
then
   which one of _those_ you need depends on specifically what you're 
doing:
   sometimes you want to indicate an actual point on the general 
timeline,
   sometimes you want to indicate how something fits into the local 
schedule
   or relates to `solar time' (e.g.: as a _nerd_, I thought it'd be a 
great idea
   to set my digital cameras' clocks to UTC and just never deal with 
DST or
   any other timezone issues when traveling..., and then as a 
_photographer_ I realized
   what a lousy idea that could end up being...).
3) sometimes you need to indicate _both_
4) you might even need to give your symbolic timezone, your timezone 
offset, _and_ UTC..., _and_

... BUT: even if you only do any arbitrary one of those things, at least you 
won't end up
mistakenly overwriting your records due to multiple distinct points in time
end up generating the same filename.

(the inverse issue, of whether you end up mistakenly _failing to generate 
collisions when you want to_
  can also be a concern of course; but I'd rather leave that as an exercise to 
the reader..., or to Ben ;p)

I *also* didn't even touch on how much all of this will annoy people who like 
nicely-sorting filenames... ;p

Every once in a while, I go back to try to find a solution to all of the other 
problems that also
fits in with _that_, and just fail. Basically..., whenever anyone asks me "what 
time is it?".
And I think I've been at that for 10 years now
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[John Abreau]

On Sat, Mar 6, 2021 at 7:48 PM Ben Scott  wrote:

> On Thu, Mar 4, 2021 at 9:57 PM Joshua Judson Rosen
>  wrote:
> > 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.
>
> Even that's not enough, because the stupid humans keep changing what
> the time zones mean.  Say you find a file that has a stored time of
> 2007 MAR 31 17:00 UTC.  If that file was written before 2005, then the
> offset to US Eastern is 5 hours.  If that file was written after 2005,
> the offset is 4 hours.  Which did the human mean when they instructed
> the computer to write the file?  No way of knowing, in the general
> case.
>

I'd argue that this case does not matter, because the human is making a
reference to an event in the future, and it is impossible in principle to
anticipate unexpected future changes in such definitions.

You could plan a vacation in Switzerland in 2030, but if an asteroid
obliterates Switzerland in 2028, your vacation plans become null and void.
It's not a contingency you need to plan for when making your vacation
plans.


-- 
John Abreau / Executive Director, Boston Linux & Unix
Email j...@blu.org / WWW http://www.abreau.net / PGP-Key-ID 0x920063C6
PGP-Key-Fingerprint A5AD 6BE1 FEFE 8E4F 5C23  C2D0 E885 E17C 9200 63C6
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Curt Howland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sunday 07 March 2021, Ben Scott was heard to say:
> If we could get all the humans to agree to follow UTC everywhere
> and just abolish time zones, things would be better, yah.  But we
> can't even get the US on the metric system, so I hold little hope
> for that.

That's the wonderful thing about standards, there are so many of them.




- -- 
You may my glories and my state dispose,
But not my griefs; still am I king of those.
 --- William Shakespeare, "Richard II"

-BEGIN PGP SIGNATURE-

iHUEAREIAB0WIQTaYVhJsIalt8scIDa2T1fo1pHhqQUCYEV/ZQAKCRC2T1fo1pHh
qQ8XAP9A1v8OGWwd0I4uwNOqAPd1Jhiw/3tGzglc2yuKE8r83wD/YOt/gRLAxfDE
22BODAUYl3fHIoYqkyJQ2e1XaR1MXBo=
=l5sX
-END PGP SIGNATURE-
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Ben Scott]

On Sat, Mar 6, 2021 at 9:17 PM Curt Howland  wrote:
>> Say you find a file that has a stored time of 2007 MAR 31 17:00 UTC.
>
> With GMT as the standard time stamp, one can at least know relative
> times of files, even if one does not know such real-world details.

There are a few problems with that theory:

(1) Not everything is the last modified date of an inode.  For
example, a file storing a time, like I gave as an example.  (Think
meetings in a calendar, messages in a mailbox, etc.)

(2) Clocks don't exist in a vacuum.  If the computer is deriving the
time from NTP or some other thing using UTC, then yes, you're good.
If the computer is deriving time from what the human typed in, you've
got trouble.  These days that's more the exception than the rule, but
not in 2007.

(3) Computers don't exist in a vacuum.  The whole point of a computer
is to automate real-world details.  True, if we didn't have humans, we
wouldn't have to worry about humans changing the time zone, or wanting
to read the time out of the computer.  But if we didn't have humans we
also wouldn't need to worry about the time being wrong either, because
the humans are the point of all this.

If we could get all the humans to agree to follow UTC everywhere and
just abolish time zones, things would be better, yah.  But we can't
even get the US on the metric system, so I hold little hope for that.

-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[jonhall80]

Especially when you go far enough north and it is never light when you wake up 
for a decent part of the year.

DST is evil. Timezones are evil. UTC is the only way.

And turtles.all the way down.

md
> On 03/06/2021 9:17 PM Curt Howland  wrote:
> 
>  
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Saturday 06 March 2021, Ben Scott was heard to say:
> > Even that's not enough, because the stupid humans keep changing
> > what the time zones mean.
> 
> With GMT as the standard time stamp, one can at least know relative 
> times of files, even if one does not know such real-world details.
> 
> I've gotten into a couple of heated arguments for/against the idea of 
> using GMT for everything, and then adapting what time things happen 
> to local conditions. The reactions to that idea have been 
> fascinating. Much like the arguments about Daylight Saving.
> 
> I mean, how silly can one be to object to it being dark when you wake 
> up, and then demanding that everyone else change the time on their 
> clocks so it's light at 7am the way you want it to be?
> 
> 
> - -- 
> You may my glories and my state dispose,
> But not my griefs; still am I king of those.
>  --- William Shakespeare, "Richard II"
> 
> -BEGIN PGP SIGNATURE-
> 
> iHUEAREIAB0WIQTaYVhJsIalt8scIDa2T1fo1pHhqQUCYEQ3sQAKCRC2T1fo1pHh
> qV4HAP9Xx2c6ThnkP137V6xTUnHTI0G6T0c8fKAByHeajP24UQEAiaWkjh3Rje1Y
> MWc8KDvpEzEpsT/vJ/kMIeaKLMbpv0k=
> =fGsr
> -END PGP SIGNATURE-
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[jonhall80]

And of course if it is an old enough date, it may be at one of those magic 
"timestamps" that never existed.

"It is turtles all the way down."


> On 03/06/2021 7:46 PM Ben Scott  wrote:
> 
>  
> On Thu, Mar 4, 2021 at 9:57 PM Joshua Judson Rosen
>  wrote:
> > 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.
> 
> Even that's not enough, because the stupid humans keep changing what
> the time zones mean.  Say you find a file that has a stored time of
> 2007 MAR 31 17:00 UTC.  If that file was written before 2005, then the
> offset to US Eastern is 5 hours.  If that file was written after 2005,
> the offset is 4 hours.  Which did the human mean when they instructed
> the computer to write the file?  No way of knowing, in the general
> case.
> 
> -- Ben
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Curt Howland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Saturday 06 March 2021, Ben Scott was heard to say:
> Even that's not enough, because the stupid humans keep changing
> what the time zones mean.

With GMT as the standard time stamp, one can at least know relative 
times of files, even if one does not know such real-world details.

I've gotten into a couple of heated arguments for/against the idea of 
using GMT for everything, and then adapting what time things happen 
to local conditions. The reactions to that idea have been 
fascinating. Much like the arguments about Daylight Saving.

I mean, how silly can one be to object to it being dark when you wake 
up, and then demanding that everyone else change the time on their 
clocks so it's light at 7am the way you want it to be?


- -- 
You may my glories and my state dispose,
But not my griefs; still am I king of those.
 --- William Shakespeare, "Richard II"

-BEGIN PGP SIGNATURE-

iHUEAREIAB0WIQTaYVhJsIalt8scIDa2T1fo1pHhqQUCYEQ3sQAKCRC2T1fo1pHh
qV4HAP9Xx2c6ThnkP137V6xTUnHTI0G6T0c8fKAByHeajP24UQEAiaWkjh3Rje1Y
MWc8KDvpEzEpsT/vJ/kMIeaKLMbpv0k=
=fGsr
-END PGP SIGNATURE-
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Ben Scott]

On Thu, Mar 4, 2021 at 9:57 PM Joshua Judson Rosen
 wrote:
> 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.

Even that's not enough, because the stupid humans keep changing what
the time zones mean.  Say you find a file that has a stored time of
2007 MAR 31 17:00 UTC.  If that file was written before 2005, then the
offset to US Eastern is 5 hours.  If that file was written after 2005,
the offset is 4 hours.  Which did the human mean when they instructed
the computer to write the file?  No way of knowing, in the general
case.

-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Bruce Labitt]

It would seem you have learned some of this the hard way.  And you are
indeed scaring me a bit.  Not sure what to do differently, however.  What
I'm hearing is properly dealing with time is hard and ugly.  I've
experienced some of this already.

I have been warned.  But, I still have to get on with things...  Can't
change the whole world, for that matter, I can't change how the cards are
written either.  So I'll have to put in (more than a few) tests to ensure
that I don't jam things up.

Thanks for passing on some of these pearls of wisdom.  I mean it.  When I
mess up, I'll remember, oh yeah, I was warned about that.  Next thought
will be, "Gosh, how am I going to fix this?"

On Fri, Mar 5, 2021, 8:54 PM Joshua Judson Rosen 
wrote:

> On 3/5/21 2:15 PM, Bruce Labitt wrote:
> >
> > 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>
> > >
> > > 
> >
> > 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.
>
> See also:
>
> http://falsehoodsabouttime.com/
>
>
> http://www.creativedeletion.com/2015/01/28/falsehoods-programmers-date-time-zones.html
>
>
> > 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!
>
> Indeed! Though I fear that the reality is actually worse than the
> impression you got
>
> A lot of the `if this happens and also' conditions are actually `if
> _either_ this _or_ that'.
>
> e.g.: most days have 86400 seconds, but...:
>
> * some have 86401 (+ leap seconds)
> * some have 86399 (- leap seconds--significantly rarer: hasn't
> happened _yet_, but...)
> * some have 82800 (i.e. "some days only have 23 hours", normal
> spring-forward DST shift)
> * some have 9 (i.e. "some days have 25 hours", normal
> fall-backward DST shift)
> * conceivably some may even have 90001 or 8
>
> (Really! RE: negative leap seconds, `there is a first time for everything':
>  <
> https://www.livescience.com/earth-spinning-faster-negative-leap-second.html
> >)
>
> And yeah..., even if you're using unix time (seconds since the epoch)...,
> unix time
> specifically does _not_ count leap seconds..., which is both wonderful and
> terrible
>
> Quoting the time(2) man page I have here:
>
> This value is not the same as the actual number of seconds between
> the time and the Epoch,
> because of leap seconds and because system clocks are not required
> to be synchronized
> to a standard reference.  The intention is that the interpretation
> of seconds since the Epoch
> values be consistent; see POSIX.1-2008 Rationale A.4.15 for
> further rationale.
>
> Wikipedia has some text on this, as well <
> https://en.wikipedia.org/wiki/Unix_time#Leap_seconds>:
>
> When a leap second occurs, the UTC day is not exactly 86400
> seconds long and the Unix time number
> (which always increases by exactly 86400 each day) experiences a
> discontinuity.
> Leap seconds may be positive or negative. No negative leap second
> has ever been declared,
> but if one were to be, then at the end of a day with a negative
> leap second,
> the Unix time number would jump up by 1 to the start of the next
> day.
> During a positive leap second at the end of a day, which occurs
> about every year and a half on average,
> the Unix time number increases continuously into the next day
> during the leap second and then at the end
> of the leap second jumps back by 1 (returning to the start of the
> next day).
>
>
> "all I have to care about is relative time" _should_ make your life
> easier..., in theory...,
> _assuming_ that the timestamps that you get and need to diff _really are_
> on a linear timescale.
>
> Good luck. I actually would love to hear about whatever linear timescale
> you end up settling on.
>
> This is why astronomers are using `Julian years'
>
>
> Oh! ALSO: I think you may have mentioned previously that you're also
> reading these files
> from a FAT-formatted SD card or something..., which is, itself, multiple
> additional sources of confusion:
>
> * FAT can only store timestamps down to *2-second* resolution,
> which means that
>   all file-timestamps get rounded to the nearest *even second*.
>
> * FAT doesn't store timestamps on an _absolute_ timescale, it only
> stores them
>   (in `broken-down time') 

Re: Kind of puzzled about timestamps

[Joshua Judson Rosen]

On 3/5/21 2:15 PM, Bruce Labitt wrote:
>
> On 3/4/21 10:51 PM, Joshua Judson Rosen wrote:
> >
> > See also: "The Problem with Time and Timezones" 
> > 
> >
> > 
>
> 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.

See also:

http://falsehoodsabouttime.com/


http://www.creativedeletion.com/2015/01/28/falsehoods-programmers-date-time-zones.html


> 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!

Indeed! Though I fear that the reality is actually worse than the impression 
you got

A lot of the `if this happens and also' conditions are actually `if _either_ 
this _or_ that'.

e.g.: most days have 86400 seconds, but...:

* some have 86401 (+ leap seconds)
* some have 86399 (- leap seconds--significantly rarer: hasn't happened 
_yet_, but...)
* some have 82800 (i.e. "some days only have 23 hours", normal 
spring-forward DST shift)
* some have 9 (i.e. "some days have 25 hours", normal fall-backward 
DST shift)
* conceivably some may even have 90001 or 8

(Really! RE: negative leap seconds, `there is a first time for everything':
 )

And yeah..., even if you're using unix time (seconds since the epoch)..., unix 
time
specifically does _not_ count leap seconds..., which is both wonderful and 
terrible

Quoting the time(2) man page I have here:

This value is not the same as the actual number of seconds between the 
time and the Epoch,
because of leap seconds and because system clocks are not required to 
be synchronized
to a standard reference.  The intention is that the interpretation of 
seconds since the Epoch
values be consistent; see POSIX.1-2008 Rationale A.4.15 for further 
rationale.

Wikipedia has some text on this, as well 
:

When a leap second occurs, the UTC day is not exactly 86400 seconds 
long and the Unix time number
(which always increases by exactly 86400 each day) experiences a 
discontinuity.
Leap seconds may be positive or negative. No negative leap second has 
ever been declared,
but if one were to be, then at the end of a day with a negative leap 
second,
the Unix time number would jump up by 1 to the start of the next day.
During a positive leap second at the end of a day, which occurs about 
every year and a half on average,
the Unix time number increases continuously into the next day during 
the leap second and then at the end
of the leap second jumps back by 1 (returning to the start of the next 
day).


"all I have to care about is relative time" _should_ make your life easier..., 
in theory...,
_assuming_ that the timestamps that you get and need to diff _really are_ on a 
linear timescale.

Good luck. I actually would love to hear about whatever linear timescale you 
end up settling on.

This is why astronomers are using `Julian years'


Oh! ALSO: I think you may have mentioned previously that you're also reading 
these files
from a FAT-formatted SD card or something..., which is, itself, multiple 
additional sources of confusion:

* FAT can only store timestamps down to *2-second* resolution, which 
means that
  all file-timestamps get rounded to the nearest *even second*.

* FAT doesn't store timestamps on an _absolute_ timescale, it only 
stores them
  (in `broken-down time') _relative to a given instantaneous timezone_.

* FAT doesn't actually give the timezone.

So..., when you for example load a FAT-formatted SD card into a Linux 
computer,
and the vfat driver in Linux needs to convert those `broken-down timestamps 
relative
to an unspecified instantaneous timezone' into `absolute seconds since the 
epoch',
IIRC it basically assumes that _Linux's current instantaneous system timezone 
offset_
is appropriate for interpreting the broken-down time stamps in the FAT 
filesystem.

If you are on the opposite side of a DST transition from when the files were 
stamped
(even if it's only 1 second of difference... or, uh..., would that be 2 
seconds?);
_or_ if you're actually in a different timezone (e.g. because you're in a 
different location),
then the timestamps will convert incorrectly.
em
If you've ever noticed that the _filesystem_ timestamps _on_ 

Re: 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" 
> 
>
> 
>
> 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.
>

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Joshua Judson Rosen]

See also: "The Problem with Time and Timezones" 




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.


-- 
Connect with me on the GNU social network! 

Not on the network? Ask me for more info!
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Bruce Labitt]

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.

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Joshua Judson Rosen]

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.

-- 
Connect with me on the GNU social network! 

Not on the network? Ask me for more info!


> On Thu, Mar 4, 2021, 7:05 PM Dana Nowell  > wrote:
> 
> If I'm reading it correctly, it's a 5 hr difference?  Local vs gmt?
> 
> 
> On Thu, Mar 4, 2021, 6:43 PM Bruce Labitt  > wrote:
> 
> This is an odd question.  It involves both python and linux.
> 
> Have a bunch of files in a directory that I'd like like to sort by 
> similar names and in time order.  This isn't particularly difficult in 
> python.  What is puzzling me is the modified timestamp returned by python 
> doesn't match whats reported by the file manager nautilus or even ls.  (ls 
> and nautilus are consistent)
> 
> $ lsb_release -d Ubuntu 20.04.2 LTS
> $ nautilus --version  GNOME nautilus 3.36.3
> 
> $ python3 --version  Python 3.8.5
> 
> $ ls -lght
> 
> total 4.7M
> -rw-r--r-- 1 bruce 209K Feb 26 01:49 20210226_022134_PLD.edf
> -rw-r--r-- 1 bruce  65K Feb 26 01:49 20210226_022134_SAD.edf
> -rw-r--r-- 1 bruce 2.4M Feb 26 01:49 20210226_022133_BRP.edf
> -rw-r--r-- 1 bruce 1.1K Feb 26 00:58 20210225_224134_EVE.edf
> -rw-r--r-- 1 bruce 1.9M Feb 25 21:18 20210225_224141_BRP.edf
> -rw-r--r-- 1 bruce 169K Feb 25 21:17 20210225_224142_PLD.edf
> -rw-r--r-- 1 bruce  53K Feb 25 21:17 20210225_224142_SAD.edf
> 
> Python3 script
> 
> #!/usr/bin/env python3
> import os
> from datetime import datetime
> 
> def convert_date(timestamp):
>   d = datetime.utcfromtimestamp(timestamp)
>   formatted_date = d.strftime('%d %b %Y  %H:%M:%S')
>   return formatted_date
> 
> with os.scandir('feb262021') as entries:
>   for entry in entries:
>     if entry.is_file():
>   info = entry.stat()
>   print(f'{entry.name }\t Last Modified: 
> {convert_date(info.st_mtime) }' )  # last modification
> 
> info /(after exit) contains/: os.stat_result(st_mode=33188, 
> st_ino=34477637, st_dev=66306, st_nlink=1, st_uid=1000, st_gid=1000, 
> st_size=213416, st_atime=1614379184, st_mtime=1614322176, st_ctime=1614379184)
> 
> Running the script results in:
> 
> 20210226_022133_BRP.edf     Last Modified: 26 Feb 2021  06:49:34
> 20210225_224141_BRP.edf     Last Modified: 26 Feb 2021  02:18:42
> 20210225_224142_PLD.edf     Last Modified: 26 Feb 2021  02:17:44
> 20210225_224142_SAD.edf     Last Modified: 26 Feb 2021  02:17:44
> 20210225_224134_EVE.edf     Last Modified: 26 Feb 2021  05:58:26
> 20210226_022134_SAD.edf     Last Modified: 26 Feb 2021  06:49:36
> 20210226_022134_PLD.edf     Last Modified: 26 Feb 2021  06:49:36
> 
> Actually, what is returned by my script is at least sensible, given 
> that 20210225_224141_BRP.edf started on Feb 25th and ended recording at 
> 2:17am on Feb 26th.  I know this because I can see the data on a separate 
> program.  20210226_022133_BRP.edf started on Feb 26th at around 2:21am and 
> terminated at 6:49am.  BRP files are written to continuously at a 25 Hz rate 
> all evening.  What makes no sense whatsoever is what *ls* is reporting.
> 
> Do *ls* and python3 use different definitions of "last modified"?
> 
> Guess I can keep going, but I really was surprised at the difference 
> between methods.  Default for ls is "last modified", at least as reported by 
> man.  ls's last modified just isn't correct, at least on Ubuntu 

Re: Kind of puzzled about timestamps

[Jerry Feldman]

Originally Unix used an epoch time system defined as the number of seconds
since January 1 1970. This was stored in a signed 32 bit integer that flips
in 2035. On 64 bit Linux systems it has been redefined as 64 bits. Unix
systems all use UTC. Linux normally uses UTC as the base, but because of
dual boot, some systems can use local time. PCs use local time. Unix and
Linux have a very rich set of time utilities.

--
Jerry Feldman 
Boston Linux and Unix http://www.blu.org
PGP key id: 6F6BB6E7
PGP Key fingerprint: 0EDC 2FF5 53A6 8EED 84D1  3050 5715 B88D 6F6
B B6E7

On Thu, Mar 4, 2021, 8:49 PM Bruce Labitt 
wrote:

> Weird, it is just the 5 hours between UT and EST.  The files are generated
> on a non-linux embedded machine.
> If I create a file on my pc, then the TZ information is present and the
> time is set.  ls reads it correctly.
>
> This time stuff can get confusing.  As you were.
> 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.
>
>
>
> On Thu, Mar 4, 2021, 7:05 PM Dana Nowell <
> dananow...@cornerstonesoftware.com> wrote:
>
>> If I'm reading it correctly, it's a 5 hr difference?  Local vs gmt?
>>
>>
>> On Thu, Mar 4, 2021, 6:43 PM Bruce Labitt 
>> wrote:
>>
>>> This is an odd question.  It involves both python and linux.
>>>
>>> Have a bunch of files in a directory that I'd like like to sort by
>>> similar names and in time order.  This isn't particularly difficult in
>>> python.  What is puzzling me is the modified timestamp returned by python
>>> doesn't match whats reported by the file manager nautilus or even ls.  (ls
>>> and nautilus are consistent)
>>> $ lsb_release -d Ubuntu 20.04.2 LTS
>>> $ nautilus --version  GNOME nautilus 3.36.3
>>>
>>> $ python3 --version  Python 3.8.5
>>>
>>> $ ls -lght
>>> total 4.7M
>>> -rw-r--r-- 1 bruce 209K Feb 26 01:49 20210226_022134_PLD.edf
>>> -rw-r--r-- 1 bruce  65K Feb 26 01:49 20210226_022134_SAD.edf
>>> -rw-r--r-- 1 bruce 2.4M Feb 26 01:49 20210226_022133_BRP.edf
>>> -rw-r--r-- 1 bruce 1.1K Feb 26 00:58 20210225_224134_EVE.edf
>>> -rw-r--r-- 1 bruce 1.9M Feb 25 21:18 20210225_224141_BRP.edf
>>> -rw-r--r-- 1 bruce 169K Feb 25 21:17 20210225_224142_PLD.edf
>>> -rw-r--r-- 1 bruce  53K Feb 25 21:17 20210225_224142_SAD.edf
>>>
>>> Python3 script
>>>
>>> #!/usr/bin/env python3
>>> import os
>>> from datetime import datetime
>>>
>>> def convert_date(timestamp):
>>>   d = datetime.utcfromtimestamp(timestamp)
>>>   formatted_date = d.strftime('%d %b %Y  %H:%M:%S')
>>>   return formatted_date
>>>
>>> with os.scandir('feb262021') as entries:
>>>   for entry in entries:
>>> if entry.is_file():
>>>   info = entry.stat()
>>>   print(f'{entry.name}\t Last Modified:
>>> {convert_date(info.st_mtime) }' )  # last modification
>>>
>>> info *(after exit) contains*: os.stat_result(st_mode=33188,
>>> st_ino=34477637, st_dev=66306, st_nlink=1, st_uid=1000, st_gid=1000,
>>> st_size=213416, st_atime=1614379184, st_mtime=1614322176,
>>> st_ctime=1614379184)
>>>
>>> Running the script results in:
>>>
>>> 20210226_022133_BRP.edf Last Modified: 26 Feb 2021  06:49:34
>>> 20210225_224141_BRP.edf Last Modified: 26 Feb 2021  02:18:42
>>> 20210225_224142_PLD.edf Last Modified: 26 Feb 2021  02:17:44
>>> 20210225_224142_SAD.edf Last Modified: 26 Feb 2021  02:17:44
>>> 20210225_224134_EVE.edf Last Modified: 26 Feb 2021  05:58:26
>>> 20210226_022134_SAD.edf Last Modified: 26 Feb 2021  06:49:36
>>> 20210226_022134_PLD.edf Last Modified: 26 Feb 2021  06:49:36
>>>
>>> Actually, what is returned by my script is at least sensible, given that
>>> 20210225_224141_BRP.edf started on Feb 25th and ended recording at
>>> 2:17am on Feb 26th.  I know this because I can see the data on a separate
>>> program.  20210226_022133_BRP.edf started on Feb 26th at around 2:21am
>>> and terminated at 6:49am.  BRP files are written to continuously at a 25 Hz
>>> rate all evening.  What makes no sense whatsoever is what *ls* is
>>> reporting.
>>>
>>> Do *ls* and python3 use different definitions of "last modified"?
>>>
>>> Guess I can keep going, but I really was surprised at the difference
>>> between methods.  Default for ls is "last modified", at least as reported
>>> by man.  ls's last modified just isn't correct, at least on Ubuntu 20.04.2
>>>
>>> Is this a quirk?  Am I doing something wrong?  Some kind of voodoo
>>> definition of "last modified"?  What does Linux say "last modified" really
>>> means?
>>>
>>> FWIW, I am coming up to speed on processing these edf files to help out
>>> on an open source project.  Been working on some data analysis tools.  As
>>> an aside, biological data is very messy.  It's been a treat to work on this
>>> as it's forced me to dust off the mental cobwebs and work on a problem that
>>> can help a lot of people.
>>>
>>>
>>> ___
>>> 

Re: Kind of puzzled about timestamps

[Bruce Labitt]

Weird, it is just the 5 hours between UT and EST.  The files are 
generated on a non-linux embedded machine.
If I create a file on my pc, then the TZ information is present and the 
time is set.  ls reads it correctly.


This time stuff can get confusing.  As you were.

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.




On Thu, Mar 4, 2021, 7:05 PM Dana Nowell 
> wrote:


If I'm reading it correctly, it's a 5 hr difference?  Local vs gmt?


On Thu, Mar 4, 2021, 6:43 PM Bruce Labitt
mailto:bruce.lab...@myfairpoint.net>> wrote:

This is an odd question.  It involves both python and linux.

Have a bunch of files in a directory that I'd like like to
sort by similar names and in time order.  This isn't
particularly difficult in python.  What is puzzling me is the
modified timestamp returned by python doesn't match whats
reported by the file manager nautilus or even ls.  (ls and
nautilus are consistent)

$ lsb_release -d Ubuntu 20.04.2 LTS
$ nautilus --version  GNOME nautilus 3.36.3

$ python3 --version  Python 3.8.5

$ ls -lght

total 4.7M
-rw-r--r-- 1 bruce 209K Feb 26 01:49 20210226_022134_PLD.edf
-rw-r--r-- 1 bruce  65K Feb 26 01:49 20210226_022134_SAD.edf
-rw-r--r-- 1 bruce 2.4M Feb 26 01:49 20210226_022133_BRP.edf
-rw-r--r-- 1 bruce 1.1K Feb 26 00:58 20210225_224134_EVE.edf
-rw-r--r-- 1 bruce 1.9M Feb 25 21:18 20210225_224141_BRP.edf
-rw-r--r-- 1 bruce 169K Feb 25 21:17 20210225_224142_PLD.edf
-rw-r--r-- 1 bruce  53K Feb 25 21:17 20210225_224142_SAD.edf

Python3 script

#!/usr/bin/env python3
import os
from datetime import datetime

def convert_date(timestamp):
  d = datetime.utcfromtimestamp(timestamp)
  formatted_date = d.strftime('%d %b %Y  %H:%M:%S')
  return formatted_date

with os.scandir('feb262021') as entries:
  for entry in entries:
    if entry.is_file():
  info = entry.stat()
  print(f'{entry.name }\t Last
Modified: {convert_date(info.st_mtime) }' )  # last modification

info /(after exit) contains/: os.stat_result(st_mode=33188,
st_ino=34477637, st_dev=66306, st_nlink=1, st_uid=1000,
st_gid=1000, st_size=213416, st_atime=1614379184,
st_mtime=1614322176, st_ctime=1614379184)

Running the script results in:

20210226_022133_BRP.edf  Last Modified: 26 Feb 2021  06:49:34
20210225_224141_BRP.edf     Last Modified: 26 Feb 2021  02:18:42
20210225_224142_PLD.edf     Last Modified: 26 Feb 2021  02:17:44
20210225_224142_SAD.edf     Last Modified: 26 Feb 2021  02:17:44
20210225_224134_EVE.edf     Last Modified: 26 Feb 2021  05:58:26
20210226_022134_SAD.edf     Last Modified: 26 Feb 2021  06:49:36
20210226_022134_PLD.edf     Last Modified: 26 Feb 2021  06:49:36

Actually, what is returned by my script is at least sensible,
given that 20210225_224141_BRP.edf started on Feb 25th and
ended recording at 2:17am on Feb 26th.  I know this because I
can see the data on a separate program.
20210226_022133_BRP.edf started on Feb 26th at around 2:21am
and terminated at 6:49am.  BRP files are written to
continuously at a 25 Hz rate all evening.  What makes no sense
whatsoever is what *ls* is reporting.

Do *ls* and python3 use different definitions of "last modified"?

Guess I can keep going, but I really was surprised at the
difference between methods.  Default for ls is "last
modified", at least as reported by man.  ls's last modified
just isn't correct, at least on Ubuntu 20.04.2

Is this a quirk?  Am I doing something wrong?  Some kind of
voodoo definition of "last modified"?  What does Linux say
"last modified" really means?

FWIW, I am coming up to speed on processing these edf files to
help out on an open source project.  Been working on some data
analysis tools.  As an aside, biological data is very messy. 
It's been a treat to work on this as it's forced me to dust
off the mental cobwebs and work on a problem that can help a
lot of people.


___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org

http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/


___
gnhlug-discuss mailing list

Re: Kind of puzzled about timestamps

[Jerry Feldman]

The time stamps are UTC. The utilities translate them using the standard
time utilities

--
Jerry Feldman 
Boston Linux and Unix http://www.blu.org
PGP key id: 6F6BB6E7
PGP Key fingerprint: 0EDC 2FF5 53A6 8EED 84D1  3050 5715 B88D 6F6
B B6E7

On Thu, Mar 4, 2021, 7:14 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.
>
>
>
> On Thu, Mar 4, 2021, 7:05 PM Dana Nowell <
> dananow...@cornerstonesoftware.com> wrote:
>
>> If I'm reading it correctly, it's a 5 hr difference?  Local vs gmt?
>>
>>
>> On Thu, Mar 4, 2021, 6:43 PM Bruce Labitt 
>> wrote:
>>
>>> This is an odd question.  It involves both python and linux.
>>>
>>> Have a bunch of files in a directory that I'd like like to sort by
>>> similar names and in time order.  This isn't particularly difficult in
>>> python.  What is puzzling me is the modified timestamp returned by python
>>> doesn't match whats reported by the file manager nautilus or even ls.  (ls
>>> and nautilus are consistent)
>>> $ lsb_release -d Ubuntu 20.04.2 LTS
>>> $ nautilus --version  GNOME nautilus 3.36.3
>>>
>>> $ python3 --version  Python 3.8.5
>>>
>>> $ ls -lght
>>> total 4.7M
>>> -rw-r--r-- 1 bruce 209K Feb 26 01:49 20210226_022134_PLD.edf
>>> -rw-r--r-- 1 bruce  65K Feb 26 01:49 20210226_022134_SAD.edf
>>> -rw-r--r-- 1 bruce 2.4M Feb 26 01:49 20210226_022133_BRP.edf
>>> -rw-r--r-- 1 bruce 1.1K Feb 26 00:58 20210225_224134_EVE.edf
>>> -rw-r--r-- 1 bruce 1.9M Feb 25 21:18 20210225_224141_BRP.edf
>>> -rw-r--r-- 1 bruce 169K Feb 25 21:17 20210225_224142_PLD.edf
>>> -rw-r--r-- 1 bruce  53K Feb 25 21:17 20210225_224142_SAD.edf
>>>
>>> Python3 script
>>>
>>> #!/usr/bin/env python3
>>> import os
>>> from datetime import datetime
>>>
>>> def convert_date(timestamp):
>>>   d = datetime.utcfromtimestamp(timestamp)
>>>   formatted_date = d.strftime('%d %b %Y  %H:%M:%S')
>>>   return formatted_date
>>>
>>> with os.scandir('feb262021') as entries:
>>>   for entry in entries:
>>> if entry.is_file():
>>>   info = entry.stat()
>>>   print(f'{entry.name}\t Last Modified:
>>> {convert_date(info.st_mtime) }' )  # last modification
>>>
>>> info *(after exit) contains*: os.stat_result(st_mode=33188,
>>> st_ino=34477637, st_dev=66306, st_nlink=1, st_uid=1000, st_gid=1000,
>>> st_size=213416, st_atime=1614379184, st_mtime=1614322176,
>>> st_ctime=1614379184)
>>>
>>> Running the script results in:
>>>
>>> 20210226_022133_BRP.edf Last Modified: 26 Feb 2021  06:49:34
>>> 20210225_224141_BRP.edf Last Modified: 26 Feb 2021  02:18:42
>>> 20210225_224142_PLD.edf Last Modified: 26 Feb 2021  02:17:44
>>> 20210225_224142_SAD.edf Last Modified: 26 Feb 2021  02:17:44
>>> 20210225_224134_EVE.edf Last Modified: 26 Feb 2021  05:58:26
>>> 20210226_022134_SAD.edf Last Modified: 26 Feb 2021  06:49:36
>>> 20210226_022134_PLD.edf Last Modified: 26 Feb 2021  06:49:36
>>>
>>> Actually, what is returned by my script is at least sensible, given that
>>> 20210225_224141_BRP.edf started on Feb 25th and ended recording at
>>> 2:17am on Feb 26th.  I know this because I can see the data on a separate
>>> program.  20210226_022133_BRP.edf started on Feb 26th at around 2:21am
>>> and terminated at 6:49am.  BRP files are written to continuously at a 25 Hz
>>> rate all evening.  What makes no sense whatsoever is what *ls* is
>>> reporting.
>>>
>>> Do *ls* and python3 use different definitions of "last modified"?
>>>
>>> Guess I can keep going, but I really was surprised at the difference
>>> between methods.  Default for ls is "last modified", at least as reported
>>> by man.  ls's last modified just isn't correct, at least on Ubuntu 20.04.2
>>>
>>> Is this a quirk?  Am I doing something wrong?  Some kind of voodoo
>>> definition of "last modified"?  What does Linux say "last modified" really
>>> means?
>>>
>>> FWIW, I am coming up to speed on processing these edf files to help out
>>> on an open source project.  Been working on some data analysis tools.  As
>>> an aside, biological data is very messy.  It's been a treat to work on this
>>> as it's forced me to dust off the mental cobwebs and work on a problem that
>>> can help a lot of people.
>>>
>>>
>>> ___
>>> gnhlug-discuss mailing list
>>> gnhlug-discuss@mail.gnhlug.org
>>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>>
>> ___
>> gnhlug-discuss mailing list
>> gnhlug-discuss@mail.gnhlug.org
>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Bruce Labitt]

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.



On Thu, Mar 4, 2021, 7:05 PM Dana Nowell 
wrote:

> If I'm reading it correctly, it's a 5 hr difference?  Local vs gmt?
>
>
> On Thu, Mar 4, 2021, 6:43 PM Bruce Labitt 
> wrote:
>
>> This is an odd question.  It involves both python and linux.
>>
>> Have a bunch of files in a directory that I'd like like to sort by
>> similar names and in time order.  This isn't particularly difficult in
>> python.  What is puzzling me is the modified timestamp returned by python
>> doesn't match whats reported by the file manager nautilus or even ls.  (ls
>> and nautilus are consistent)
>> $ lsb_release -d Ubuntu 20.04.2 LTS
>> $ nautilus --version  GNOME nautilus 3.36.3
>>
>> $ python3 --version  Python 3.8.5
>>
>> $ ls -lght
>> total 4.7M
>> -rw-r--r-- 1 bruce 209K Feb 26 01:49 20210226_022134_PLD.edf
>> -rw-r--r-- 1 bruce  65K Feb 26 01:49 20210226_022134_SAD.edf
>> -rw-r--r-- 1 bruce 2.4M Feb 26 01:49 20210226_022133_BRP.edf
>> -rw-r--r-- 1 bruce 1.1K Feb 26 00:58 20210225_224134_EVE.edf
>> -rw-r--r-- 1 bruce 1.9M Feb 25 21:18 20210225_224141_BRP.edf
>> -rw-r--r-- 1 bruce 169K Feb 25 21:17 20210225_224142_PLD.edf
>> -rw-r--r-- 1 bruce  53K Feb 25 21:17 20210225_224142_SAD.edf
>>
>> Python3 script
>>
>> #!/usr/bin/env python3
>> import os
>> from datetime import datetime
>>
>> def convert_date(timestamp):
>>   d = datetime.utcfromtimestamp(timestamp)
>>   formatted_date = d.strftime('%d %b %Y  %H:%M:%S')
>>   return formatted_date
>>
>> with os.scandir('feb262021') as entries:
>>   for entry in entries:
>> if entry.is_file():
>>   info = entry.stat()
>>   print(f'{entry.name}\t Last Modified: {convert_date(info.st_mtime)
>> }' )  # last modification
>>
>> info *(after exit) contains*: os.stat_result(st_mode=33188,
>> st_ino=34477637, st_dev=66306, st_nlink=1, st_uid=1000, st_gid=1000,
>> st_size=213416, st_atime=1614379184, st_mtime=1614322176,
>> st_ctime=1614379184)
>>
>> Running the script results in:
>>
>> 20210226_022133_BRP.edf Last Modified: 26 Feb 2021  06:49:34
>> 20210225_224141_BRP.edf Last Modified: 26 Feb 2021  02:18:42
>> 20210225_224142_PLD.edf Last Modified: 26 Feb 2021  02:17:44
>> 20210225_224142_SAD.edf Last Modified: 26 Feb 2021  02:17:44
>> 20210225_224134_EVE.edf Last Modified: 26 Feb 2021  05:58:26
>> 20210226_022134_SAD.edf Last Modified: 26 Feb 2021  06:49:36
>> 20210226_022134_PLD.edf Last Modified: 26 Feb 2021  06:49:36
>>
>> Actually, what is returned by my script is at least sensible, given that
>> 20210225_224141_BRP.edf started on Feb 25th and ended recording at
>> 2:17am on Feb 26th.  I know this because I can see the data on a separate
>> program.  20210226_022133_BRP.edf started on Feb 26th at around 2:21am
>> and terminated at 6:49am.  BRP files are written to continuously at a 25 Hz
>> rate all evening.  What makes no sense whatsoever is what *ls* is
>> reporting.
>>
>> Do *ls* and python3 use different definitions of "last modified"?
>>
>> Guess I can keep going, but I really was surprised at the difference
>> between methods.  Default for ls is "last modified", at least as reported
>> by man.  ls's last modified just isn't correct, at least on Ubuntu 20.04.2
>>
>> Is this a quirk?  Am I doing something wrong?  Some kind of voodoo
>> definition of "last modified"?  What does Linux say "last modified" really
>> means?
>>
>> FWIW, I am coming up to speed on processing these edf files to help out
>> on an open source project.  Been working on some data analysis tools.  As
>> an aside, biological data is very messy.  It's been a treat to work on this
>> as it's forced me to dust off the mental cobwebs and work on a problem that
>> can help a lot of people.
>>
>>
>> ___
>> gnhlug-discuss mailing list
>> gnhlug-discuss@mail.gnhlug.org
>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Dana Nowell]

If I'm reading it correctly, it's a 5 hr difference?  Local vs gmt?


On Thu, Mar 4, 2021, 6:43 PM Bruce Labitt 
wrote:

> This is an odd question.  It involves both python and linux.
>
> Have a bunch of files in a directory that I'd like like to sort by similar
> names and in time order.  This isn't particularly difficult in python.
> What is puzzling me is the modified timestamp returned by python doesn't
> match whats reported by the file manager nautilus or even ls.  (ls and
> nautilus are consistent)
> $ lsb_release -d Ubuntu 20.04.2 LTS
> $ nautilus --version  GNOME nautilus 3.36.3
>
> $ python3 --version  Python 3.8.5
>
> $ ls -lght
> total 4.7M
> -rw-r--r-- 1 bruce 209K Feb 26 01:49 20210226_022134_PLD.edf
> -rw-r--r-- 1 bruce  65K Feb 26 01:49 20210226_022134_SAD.edf
> -rw-r--r-- 1 bruce 2.4M Feb 26 01:49 20210226_022133_BRP.edf
> -rw-r--r-- 1 bruce 1.1K Feb 26 00:58 20210225_224134_EVE.edf
> -rw-r--r-- 1 bruce 1.9M Feb 25 21:18 20210225_224141_BRP.edf
> -rw-r--r-- 1 bruce 169K Feb 25 21:17 20210225_224142_PLD.edf
> -rw-r--r-- 1 bruce  53K Feb 25 21:17 20210225_224142_SAD.edf
>
> Python3 script
>
> #!/usr/bin/env python3
> import os
> from datetime import datetime
>
> def convert_date(timestamp):
>   d = datetime.utcfromtimestamp(timestamp)
>   formatted_date = d.strftime('%d %b %Y  %H:%M:%S')
>   return formatted_date
>
> with os.scandir('feb262021') as entries:
>   for entry in entries:
> if entry.is_file():
>   info = entry.stat()
>   print(f'{entry.name}\t Last Modified: {convert_date(info.st_mtime)
> }' )  # last modification
>
> info *(after exit) contains*: os.stat_result(st_mode=33188,
> st_ino=34477637, st_dev=66306, st_nlink=1, st_uid=1000, st_gid=1000,
> st_size=213416, st_atime=1614379184, st_mtime=1614322176,
> st_ctime=1614379184)
>
> Running the script results in:
>
> 20210226_022133_BRP.edf Last Modified: 26 Feb 2021  06:49:34
> 20210225_224141_BRP.edf Last Modified: 26 Feb 2021  02:18:42
> 20210225_224142_PLD.edf Last Modified: 26 Feb 2021  02:17:44
> 20210225_224142_SAD.edf Last Modified: 26 Feb 2021  02:17:44
> 20210225_224134_EVE.edf Last Modified: 26 Feb 2021  05:58:26
> 20210226_022134_SAD.edf Last Modified: 26 Feb 2021  06:49:36
> 20210226_022134_PLD.edf Last Modified: 26 Feb 2021  06:49:36
>
> Actually, what is returned by my script is at least sensible, given that
> 20210225_224141_BRP.edf started on Feb 25th and ended recording at 2:17am
> on Feb 26th.  I know this because I can see the data on a separate
> program.  20210226_022133_BRP.edf started on Feb 26th at around 2:21am
> and terminated at 6:49am.  BRP files are written to continuously at a 25 Hz
> rate all evening.  What makes no sense whatsoever is what *ls* is
> reporting.
>
> Do *ls* and python3 use different definitions of "last modified"?
>
> Guess I can keep going, but I really was surprised at the difference
> between methods.  Default for ls is "last modified", at least as reported
> by man.  ls's last modified just isn't correct, at least on Ubuntu 20.04.2
>
> Is this a quirk?  Am I doing something wrong?  Some kind of voodoo
> definition of "last modified"?  What does Linux say "last modified" really
> means?
>
> FWIW, I am coming up to speed on processing these edf files to help out on
> an open source project.  Been working on some data analysis tools.  As an
> aside, biological data is very messy.  It's been a treat to work on this as
> it's forced me to dust off the mental cobwebs and work on a problem that
> can help a lot of people.
>
>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/