1. Forum
  2. Newsgroups
  3. comp.os.linux.misc

  • Re:=?utf-8?B?UGFja2FnZXMgV2l0aCDigJx0NjTigJ0gT24gVGhlIEVuZHMgT2YgVGhlaXI=?==?utf-8?B?IE5hbWVz?=

    From David W. Hodgins@dwhodgins@nomail.afraid.org to comp.os.linux.misc,nz.comp on Thu Apr 18 18:19:29 2024
    From Newsgroup: comp.os.linux.misc

    On Thu, 18 Apr 2024 16:35:55 -0400, The Natural Philosopher <tnp@invalid.invalid> wrote:
    On 18/04/2024 16:00, candycanearter07 wrote:
    Woozy Song <suzyw0ng@outlook.com> wrote at 01:22 this Wednesday (GMT):
    Marc Haber wrote:
    Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
    On 64-bit systems (which is what most of us would be running by now), >>>> You need to think beyond your desktop PC. Linux runs on billions of
    embedded systems, many of them being a 32 bit architecture and bound
    to stay there. Embedded systems tend to have an order of magnitude
    more in lifetime. The year 2038 is already here for those systems.


    So don't get in an elevator on Jan 18/19 2038?

    Hopefully it's like Y2K where not too much happens

    A lot of legacy COBOL had to be fixed, just not linux

    I first ran into the century problem in the early 1980's, in a COBOL program that dealt with rail stock for a Canadian railway company. Some of the cars have frames built in the 1800's. The wheel assemblies (truks) and couplers
    had been replaced multiple times, but the cars themselves were over 100 years old. That was when I first started insisting on keeping 4 digit years in systems
    I designed or was able to get altered.

    Just as y2k was minor, I expect 2038 will be too. Most programs store human readable dates, not seconds since epoch timestamps.

    Of those that do store timestamps, only those that require the data to be in date and/or time order will need to have workarounds or fixes. Very few of those
    are used in critical situations.

    Reviewing and fixing all of the code will take a lot of time, but the impact
    of failing to do that will rarely have important impacts.

    Regards, Dave Hodgins
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Lawrence D'Oliveiro@ldo@nz.invalid to comp.os.linux.misc,nz.comp on Fri Apr 19 00:57:37 2024
    From Newsgroup: comp.os.linux.misc

    On Thu, 18 Apr 2024 18:19:29 -0400, David W. Hodgins wrote:

    Most programs store human readable dates, not seconds since epoch
    timestamps.

    *Cough* no. But my code (that I can think of) is a) not written in C, and
    b) stores these timestamps in database fields, which can be easily
    redefined.
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Marc Haber@mh+usenetspam1118@zugschl.us to comp.os.linux.misc,nz.comp on Fri Apr 19 07:30:50 2024
    From Newsgroup: comp.os.linux.misc

    Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
    On Thu, 18 Apr 2024 18:19:29 -0400, David W. Hodgins wrote:

    Most programs store human readable dates, not seconds since epoch
    timestamps.

    *Cough* no. But my code (that I can think of) is a) not written in C, and
    b) stores these timestamps in database fields, which can be easily >redefined.

    That depends whether you consider an "ALTER TABLE" call for a BIG
    table "easy" or not. It's something that many database admins work
    hard to avoid.

    Greetings
    Marc
    -- ---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
    Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
    --- Synchronet 3.20a-Linux NewsLink 1.114