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.com@nanog.org> On Behalf Of Stephane Bortzmeyer Sent: Wednesday, August 3, 2022 11:19 AM To: Jay Ashworth <jra@baylink.com> Cc: nanog@nanog.org Subject: Re: IERS ponders reverse leapsecond...
On Wed, Aug 03, 2022 at 11:09:25AM -0400, Jay Ashworth <jra@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 beckman@angryox.com https://www.angryox.com/ ---------------------------------------------------------------------------