From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2842 invoked from network); 6 Jan 2021 07:22:51 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 6 Jan 2021 07:22:51 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 04F299C87B; Wed, 6 Jan 2021 17:22:50 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 1F63E9C793; Wed, 6 Jan 2021 17:22:09 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=bsdimp-com.20150623.gappssmtp.com header.i=@bsdimp-com.20150623.gappssmtp.com header.b="PFJcpIda"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id F0D4B9C792; Wed, 6 Jan 2021 17:22:05 +1000 (AEST) Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51]) by minnie.tuhs.org (Postfix) with ESMTPS id 063BF9C793 for ; Wed, 6 Jan 2021 17:22:04 +1000 (AEST) Received: by mail-qv1-f51.google.com with SMTP id a4so855065qvd.12 for ; Tue, 05 Jan 2021 23:22:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W4aAKpq6wjfnEbQiMAthunbEQie8jQv26G1wL2eEnj4=; b=PFJcpIdaFr/pLX8p4sPGK7gb6D7QLjxA4aiSHSMiqxW/65eZTKpo74NSbmx6/nSBa1 rfjw3MeFpsV72boQzHyNaVWH0zYH0CWKWvXhlHLfipIzMX3i+zCQ//zWxhALgwteo+gN cFAEADL/jDPljcf66OyU1fU1dDtDBzimAIPirWDrw0yB2M9z8SZ8Jp93TRXkisAVFXFg pdks0D8t5OW7y7P8S9eipDFptg6eS99ZlQZF/czvbj53xH+4dwKsjtja9BWLNc3o+oEv HCfGZiPpzDRqbdq8CIa2WcfjGOoyVcnEWw4Ordpz7N9wzjjh3tG/0Nw9kDLc4gndYk80 ac6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W4aAKpq6wjfnEbQiMAthunbEQie8jQv26G1wL2eEnj4=; b=UsPbPS5IP+rZWd9akaqwd7NxiMhSc85GGr82714kE0R8KP6WLLiYLxpq4MffFKEbkO D9xdDyjIyp8pwAA4bVxOa5+S9cJy5Rp/7EkPS3T6AIe9R5ZeYIMlsyBMbk3hpzqXogUw R4WaeFij3Qn4tY7B6WukylMIu3dbdY75B84zXsPJKaWYIv+RYj2ufMbGYqv4A15MeU9r 6wK5hhn2fU74dsWKRN03ey86WX1UsHZhETtEKWfMjh+9zJuRqQmk1YZzK/7RTJ2+7H8c PEmedlMZvn3Y0epg4965eF9mVytbuqXgo1/pRt5sZwDah4L5ambyzZ6x69ruPt0sERZ4 CBfQ== X-Gm-Message-State: AOAM533hv/GKVv9k691lCybFmzIpSEG+PqsFofBxTjQZoePy0GfOf93P 86Ok/LdX6cR1nXtbFp0BnMMv51XPXc6i+k3bloOOgQ== X-Google-Smtp-Source: ABdhPJx4maGKkz8wTERf8p3EixYu8Lo8SqITnLbKoSm9vZYTG4ZdU3Jji8q8O4VxS5UOWWCNMV30SVAW9cqVVJS9/oo= X-Received: by 2002:a0c:f14c:: with SMTP id y12mr2989313qvl.23.1609917722950; Tue, 05 Jan 2021 23:22:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 6 Jan 2021 00:21:51 -0700 Message-ID: To: Dan Cross Content-Type: multipart/alternative; boundary="000000000000fe976d05b8362df7" Subject: Re: [TUHS] The 2038 bug... X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000fe976d05b8362df7 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 5, 2021 at 11:06 AM Dan Cross wrote: > On Mon, Jan 4, 2021 at 4:57 PM Warner Losh wrote: > >> On Mon, Jan 4, 2021 at 2:50 PM Dave Horsfall wrote: >> >>> On Mon, 4 Jan 2021, Peter Jeremy wrote: >>> >>> > Alternatively, my understanding is that the Unix epoch changed on >>> > several occasions in the early days. Presumably the knowledge of how >>> to >>> > achieve this hasn't been lost. (Though actually performing an epoch >>> > rollover may be more difficult today). >>> >>> My understanding is that it's been 1st Jan 1970 since at least Ed5, if >>> not >>> Ed6. >>> >> >> It's been that way since the 4th edition. >> >> In the 3rd edition it was the number of 60Hz ticks since 1972, along with >> this note: "This guarantees a crisis every 2.26 years." >> >> Rebasing the epoch would be... tricky... lots of math is done assuming >> an origin of 1970, and not all of it is obvious to even concerted analysis. >> >> Less ugly would be to declare time_t to be unsigned instead of signed... >> It would break less code... Making time_t 64 bits also breaks code, even if >> you declare you don't care about binary compat since many older apps know >> time_t is 32-bits. >> > > Lots of older code also knew that pointers were 32 bits and could fit into > an int, that the signal bitmask fit into 32 bits, etc. I feel like we have > these crises every few years and we work around them. The issues here are > perfectly familiar. > True. The issues were understood for years before compilers started warning about the issue on a wide-scale basis. There's currently no warnings for many of the common time_t type handling mistakes since they aren't considered errors in other contexts. So it makes the problem less visible. > A saving grace is that the timestamp fields in Unixy filesystems are > almost invariably 64 bits and have been for a few decades now. Unlike y2k, > the persistence issue is largely fixed except for ersatz binary formats, > and most decently-maintained software hides the width of time behind a > typedef. As for Ted's vignette about hand-coded systems in PDP-11 assembler > running under emulation, I think the issue here is somewhat different: in > this case, by and large, the software doesn't need rewriting, but rather > recompilation on a new hardware and/or OS platform, possibly with some > modifications to fix assumptions about type width. That's qualitatively > different from rewriting from scratch in a different language on a > radically different platform. Note I'm talking about Unix and Linux here, > as opposed to other systems with similar epoch issues. > A larger problem, though, is where time_t is 64 bits, but on-disk format is 32-bits... And often times recompiling old software on new systems with different sized types can be a crap shoot. For software that's well understood, sure, an analysis can be undertaken, and it will likely work. For older code, that uses tricks to compute different types of dates, it's also likely more prone to overflow even with the recompile... > Certainly there will be some breakage in 2038. But I suspect that we'll > pull a y2k and the critical stuff will be mostly fixed by the time the > epoch rolls over. The long tail will be annoying, as it was with y2k, but > not necessarily critical. > I suspect that many of the issues can be fixed between now and then, but w/o some effort, they will persist... Though it doesn't take too many errors in a critical system for there to be a catastrophic failure. Without publicity like y2k got, it's unclear the outcome. I'll note with pride that my state replaced its unemployment system today with a new one. The old one was only 44 years old and not even the oldest in the nation... The long hand of the past appears in unexpected locations that are resource constrained. Warner > - Dan C. > > --000000000000fe976d05b8362df7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 5, 2021 at 11:06 AM Dan C= ross <crossd@gmail.com> wrote= :
On Mon, Jan 4, 2021 at 4:57 PM Warner Losh <imp@bsdimp.com> wrote:<= /div>
On Mon, Jan 4, 2021 at 2:50 PM Dave Horsfall <dave@horsfall.org> wrot= e:
On Mon, 4 Jan= 2021, Peter Jeremy wrote:

> Alternatively, my understanding is that the Unix epoch changed on
> several occasions in the early days.=C2=A0 Presumably the knowledge of= how to
> achieve this hasn't been lost.=C2=A0 (Though actually performing a= n epoch
> rollover may be more difficult today).

My understanding is that it's been 1st Jan 1970 since at least Ed5, if = not
Ed6.

It's been that way since the 4= th edition.

In the 3rd edition it was the number o= f 60Hz ticks since 1972, along with this note: "This guarantees a cris= is every 2.26 years."

Rebasing the epoch woul= d be...=C2=A0 tricky... lots of math is done assuming an origin of 1970, an= d not all of it is obvious to even concerted analysis.

=
Less ugly would be to declare time_t to be unsigned instead of signed.= ..=C2=A0 It would break less code... Making time_t 64 bits also breaks code= , even if you declare you don't care about binary compat since many old= er apps know time_t is 32-bits.

Lots of older code also knew that pointers were 32 bits and could fi= t into an int, that the signal bitmask fit into 32 bits, etc. I feel like w= e have these crises every few years and we work around them. The issues her= e are perfectly familiar.

True. The issues were understood for years before compilers started warnin= g about the issue on a wide-scale basis. There's currently no warnings = for many of the common time_t type handling mistakes since they aren't = considered errors in other contexts. So it makes the problem less visible.<= /div>
=C2=A0
A saving grace is that the ti= mestamp fields in Unixy=C2=A0filesystems are almost invariably 64 bits and = have been for a few decades now. Unlike y2k, the persistence issue is large= ly fixed except for ersatz binary formats, and most decently-maintained sof= tware hides the width of time behind a typedef. As for Ted's vignette a= bout hand-coded systems in PDP-11 assembler running under emulation, I thin= k the issue here is somewhat different: in this case, by and large, the sof= tware doesn't need rewriting, but rather recompilation on a new hardwar= e and/or OS platform, possibly with some modifications to fix assumptions a= bout type width. That's qualitatively different from rewriting from scr= atch in a different language on a radically different platform. Note I'= m talking about Unix and Linux here, as opposed to other systems with simil= ar epoch issues.

A larger= problem, though, is where time_t is 64 bits, but on-disk format is 32-bits= ... And often times=C2=A0recompiling old software on new systems with diffe= rent sized types can be a crap shoot. For software that's well understo= od, sure, an analysis can be undertaken, and it will likely work. For older= code, that uses tricks to compute different types of dates, it's also = likely more prone to overflow even with the recompile...
=C2=A0
=
Certainly there will be some breakage in 20= 38. But I suspect that we'll pull a y2k and the critical stuff will be = mostly fixed by the time the epoch rolls over. The long tail will be annoyi= ng, as it was with y2k, but not necessarily critical.

I suspect that many of the issues can be fixed= between now and then, but w/o some effort, they will persist...=C2=A0 Thou= gh it doesn't take too many errors in a critical system for there to be= a catastrophic=C2=A0failure. Without publicity like y2k got, it's uncl= ear the outcome.

I'll note with pride that my = state replaced its unemployment system today with a new one. The old one wa= s only 44 years old and not even the oldest in the nation... The long hand = of the past appears in unexpected locations that are resource constrained.<= /div>

Warner
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.

--000000000000fe976d05b8362df7--