On Wed, 3 Aug 2022, Matthew Huff wrote:
But it's hard enough to get developers to understand the need to code for
61 seconds in a minute, and now they would need to code for 59 seconds as
well.
If time systems simply skewed the time so that 60 seconds actually just
took 61 seconds or 59 seconds, there would be other issues, but coders
wouldn't be involved.
Code will always be prone to failure due to inconsistent and incorrect
assumptions. And blindly trusting dependencies.
Hell, even the smartest engineers at Amazon built AWS using Pacific Time
in the DB rather than GMT/UTC. It was still Pacific Time when I left in
2014.
I'm sure there is/was code to calculate billing related to the jump
forward / fall back between Daylight Saving and Standard Time...
I'm looking forward to January 19, 2038 at 3:14am UTC when the 32-bit Unix
Timestamp will overflow.
This shouldn't cause huge issues, as most systems will not freak out and
die if the system clocks goes from 23:59:58 to 00:00:00. But things that
were supposed to happen at 23:59:59 on that day will never occur.
Hopefully the impact is minimal, but it won't be none.
-----Original Message-----
From: NANOG <nanog-bounces+mhuff=ox....@nanog.org> On Behalf Of Stephane
Bortzmeyer
Sent: Wednesday, August 3, 2022 11:19 AM
To: Jay Ashworth <j...@baylink.com>
Cc: nanog@nanog.org
Subject: Re: IERS ponders reverse leapsecond...
On Wed, Aug 03, 2022 at 11:09:25AM -0400, Jay Ashworth <j...@baylink.com>
wrote a message of 32 lines which said:
General press loses its *mind*:
Indeed, they seem not to know what they write about. "atomic time – the universal
way time is measured on Earth – may have to change" They don't even know the
difference between TAI and UTC.
---------------------------------------------------------------------------
Peter Beckman Internet Guy
beck...@angryox.com https://www.angryox.com/
---------------------------------------------------------------------------
