1. Forum
  2. Usenet
  3. COMP.LANG.FORTRAN

  • xkcd: Y2K and 2038

    From Lynn McGuire@21:1/5 to All on Fri Nov 11 14:29:54 2022
    XPost: comp.lang.c, comp.lang.c++

    xkcd: Y2K and 2038
    https://xkcd.com/2697/

    It shouldn't cost more than a trillion dollars or two to investigate this.

    Explained at:
    https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Lynn McGuire on Fri Nov 11 20:31:05 2022
    On Saturday, November 12, 2022 at 7:30:00 AM UTC+11, Lynn McGuire wrote:
    xkcd: Y2K and 2038
    https://xkcd.com/2697/

    It shouldn't cost more than a trillion dollars or two to investigate this.

    Explained at:
    https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038
    .
    PL/I uses a double word float.
    It handled the Y2K problem with minimal changes to programs.
    .
    Banks didn't learn anything from Y2K: they still use 2-digit years.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Thomas Koenig on Sat Nov 12 00:02:13 2022
    On Saturday, November 12, 2022 at 6:36:59 PM UTC+11, Thomas Koenig wrote:
    Lynn McGuire <lynnmc...@gmail.com> schrieb:
    xkcd: Y2K and 2038
    https://xkcd.com/2697/

    It shouldn't cost more than a trillion dollars or two to investigate this.
    The switchover to 64-bit systems should have done this. Not sure
    that this cost a trillion dollars, but computers usually have a
    limited lifetime, so they had to be replaced anyway.
    .
    It requires software to use functions that deal with dates beyond 2038.
    .
    PL/I already can handle years beyond 2038, as mentioned.
    .
    BTW, it also requires companies to use 4-digit years.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Lynn McGuire on Sat Nov 12 07:36:56 2022
    XPost: comp.lang.c, comp.lang.c++

    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
    xkcd: Y2K and 2038
    https://xkcd.com/2697/

    It shouldn't cost more than a trillion dollars or two to investigate this.

    The switchover to 64-bit systems should have done this. Not sure
    that this cost a trillion dollars, but computers usually have a
    limited lifetime, so they had to be replaced anyway.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Lynn McGuire on Sat Nov 12 06:49:34 2022
    On Saturday, November 12, 2022 at 2:58:50 AM UTC-5, Lynn McGuire wrote:

    ..

    Porting software to 64 bit is a tremendous work for most software.

    Re: "Porting software to 64 bit is a tremendous work for most software", no this is inaccurate. It is "tremendous work" for *only* certain software that have followed platform-dependent nonportable and other coding practices for far too long that have
    been flagged as problematic on many forums and literature.

    ISO IEC standard-conforming Fortran codes have long worked portably across different versions of 32-bit and 64-bit versions of Microsoft OS, my first experience with one such code was way back in 2010 on 32-bit and 64-bit Windows 7 which gave me my first
    introduction to the Fortran 2008 standard. That later had me dig deeper into Fortran 2008 followed by Fortran 2015 that eventually got renamed to Fortran 2018.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Scott Lurndal on Sat Nov 12 10:46:59 2022
    On Saturday, November 12, 2022 at 8:05:19 AM UTC-8, Scott Lurndal wrote:
    (snip)

    And how much of that software uses time_t?

    I suspect that a lot of software uses time_t, but more important,
    is where it uses it.

    Many compilers, and probably other programs, output a listing file
    with the date on top. It won't fail, but will print out the wrong date.

    There is a story, many years old by now, of some DEC system that kept dates with not enough bits. That one had something like make, to decide which files to compile based on the date last changed. That failed at a surprising time, but then got fixed, too.

    I suspect that by now, most of the important dates are in DBMS systems,
    and will automatically, and invisibly, have enough bits.

    And Y2K wasn't really as bad as some thought. I do remember a credit card
    that didn't work, only once, with expiration date after 2000. That depended on every individual little terminal, and some were updated slowly. Note that the actual failure wasn't in the year 2000, though.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Thomas Koenig on Sat Nov 12 11:56:56 2022
    On Saturday, November 12, 2022 at 11:30:18 AM UTC-8, Thomas Koenig wrote:

    (snip)

    Many compilers, and probably other programs, output a listing file
    with the date on top.

    It would be interesting to see which current compilers still do this.
    VS Fortran probably still does, but it is stuck at FORTRAN 77,
    and I can hardly call that "current".

    For the IBM compilers, the default is a sysgen option.
    The ones I knew had it on by default, but you can always
    turn it off. The option is SOURCE or NOSOURCE.
    The LIST and NOLIST options give you the listing
    of the generated assembly code, though not in the
    form that an assembler will accept.

    None of the UNIX-oriented compilers do (the tradition was always to
    be as quiet as possible), and also not Windows compilers. gfortran
    does not even have an option to produce a source listing.

    I haven't thought about it so recently. I thought the usual Unix
    compilers would do it, but not by default.

    It seems that gcc has options starting with --fdump
    to generate various files with (hopefully) useful information,
    and which might have dates in them.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to gah4@u.washington.edu on Sat Nov 12 19:30:15 2022
    gah4 <gah4@u.washington.edu> schrieb:
    On Saturday, November 12, 2022 at 8:05:19 AM UTC-8, Scott Lurndal wrote: (snip)

    And how much of that software uses time_t?

    I suspect that a lot of software uses time_t, but more important,
    is where it uses it.

    Many compilers, and probably other programs, output a listing file
    with the date on top.

    It would be interesting to see which current compilers still do this.
    VS Fortran probably still does, but it is stuck at FORTRAN 77,
    and I can hardly call that "current".

    None of the UNIX-oriented compilers do (the tradition was always to
    be as quiet as possible), and also not Windows compilers. gfortran
    does not even have an option to produce a source listing.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to gah4@u.washington.edu on Sat Nov 12 23:45:07 2022
    gah4 <gah4@u.washington.edu> schrieb:
    On Saturday, November 12, 2022 at 11:30:18 AM UTC-8, Thomas Koenig wrote:

    None of the UNIX-oriented compilers do (the tradition was always to
    be as quiet as possible), and also not Windows compilers. gfortran
    does not even have an option to produce a source listing.

    I haven't thought about it so recently. I thought the usual Unix
    compilers would do it, but not by default.

    It seems that gcc has options starting with --fdump
    to generate various files with (hopefully) useful information,
    and which might have dates in them.

    You can do -fdump-fortran-original to get at the internal syntax
    tree, and -fdump-tree-original to see what the Fortran front end
    hands to the middle end. It is quite instructive to see what
    a simple Fortran statement can result in...

    No date information, though.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Keith Thompson on Sat Nov 12 18:08:29 2022
    On Saturday, November 12, 2022 at 6:00:09 PM UTC-8, Keith Thompson wrote:

    (snip)

    The real problem is going to be 32-bit (or smaller) embedded systems
    whose software can't be updated. On the other hand, a lot of such
    systems probably don't care what time it is.

    As I noted, the only Y2K problem that happened to me was from a credit
    card terminal. As I understand it, the terminal checks the date before
    sending the request off to the remote system.

    However, the problems with smaller systems are smaller.
    If one terminal fails, the rest of the system keeps going.

    But also, small systems are doing better at being upgradable.

    I just found out that the computer system inside our car can be
    upgraded through WiFi. It turns out that our home WiFi reaches
    out to the street. Just about anything with firmware in flash,
    and a USB or network connection, now allows for upgrade.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Klaus Wacker@21:1/5 to Klaus Wacker on Sun Nov 13 13:23:49 2022
    In comp.lang.fortran Klaus Wacker <klaus.w.wacker@t-online.de> wrote:

    My contribution to the 2038 problem:


    [program text deleted]

    Of course you are welcome to add languages.

    --
    Klaus Wacker klaus.w.wacker@t-online.de
    51°29'7"N 7°25'7"E

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From red floyd@21:1/5 to Keith Thompson on Sun Nov 13 09:49:54 2022
    XPost: comp.lang.c, comp.lang.c++

    On 11/12/2022 6:00 PM, Keith Thompson wrote:
    On the other hand, a lot of such
    systems probably don't care what time it is.

    Why am I thinking of Chicago now?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to David Brown on Mon Nov 14 01:54:49 2022
    On Monday, November 14, 2022 at 1:09:40 AM UTC-8, David Brown wrote:

    (snip)

    Small embedded systems which also track the date will generally not do
    so using Unix epoch timestamps - it's a lot easier to hold a structure
    with second, minute, hour, day, month, year fields and update it. That
    avoids all the mess of locales and time and date conversions.

    Reminds me that I have a sprinkler timer that you program with the year.
    It needs the year because you can set it to water on even or odd days,
    and so has to get leap years right.

    But if it watered on the wrong day, it wouldn't be the worst thing.

    You can program it by week days, then it doesn't even need the month,
    but you still have to set year and month.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Klaus Wacker@21:1/5 to Keith Thompson on Mon Nov 14 13:47:36 2022
    XPost: comp.lang.c, comp.lang.c++

    In comp.lang.fortran Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    [...]

    An unsigned time_t makes it impossible to represent times before 1970.
    Not all software is going to care about that, but in my opinion it's
    an unacceptable price.


    I read somewhere that the reason for a signed time_t was mainly that
    this type was nor just used for time stamps, but also for time
    differences.

    --
    Klaus Wacker klaus.w.wacker@t-online.de
    51°29'7"N 7°25'7"E

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gary Scott@21:1/5 to All on Mon Nov 14 09:41:37 2022
    On 11/14/2022 3:54 AM, gah4 wrote:
    On Monday, November 14, 2022 at 1:09:40 AM UTC-8, David Brown wrote:

    (snip)

    Small embedded systems which also track the date will generally not do
    so using Unix epoch timestamps - it's a lot easier to hold a structure
    with second, minute, hour, day, month, year fields and update it. That
    avoids all the mess of locales and time and date conversions.

    Reminds me that I have a sprinkler timer that you program with the year.
    It needs the year because you can set it to water on even or odd days,
    and so has to get leap years right.

    But if it watered on the wrong day, it wouldn't be the worst thing.

    Unless code enforcement catches you watering on the wrong day ... :(


    You can program it by week days, then it doesn't even need the month,
    but you still have to set year and month.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Lynn McGuire on Fri Dec 2 05:53:06 2022
    On Saturday, November 12, 2022 at 6:58:50 PM UTC+11, Lynn McGuire wrote:
    On 11/12/2022 1:36 AM, Thomas Koenig wrote:
    Lynn McGuire <lynnmc...@gmail.com> schrieb:
    xkcd: Y2K and 2038
    https://xkcd.com/2697/

    It shouldn't cost more than a trillion dollars or two to investigate this.

    The switchover to 64-bit systems should have done this. Not sure
    that this cost a trillion dollars, but computers usually have a
    limited lifetime, so they had to be replaced anyway.
    Most software is still 32 bit. Having the operating system as 64 bit
    helps but it does not solve the problem of the 32 bit software running
    on it. An unsigned 32 bit integer only gets us to 2106.
    .
    Are you planning to live for 150 years?
    .
    https://en.wikipedia.org/wiki/Year_2038_problem

    Porting software to 64 bit is a tremendous work for most software.
    .
    Not for PL/I.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)