4 ms·

Why is anyone using two-digit years anywhere at all? This approach has already caused a lot of trouble 22 years ago. Do people learn nothing from their past mis

Why is anyone using two-digit years anywhere at all? This approach has already caused a lot of trouble 22 years ago. Do people learn nothing from their past mistakes?

btgeekboy 5y ago
Because these files aren't going backward in time, and it's quite unlikely this code will be in use in 78 years.
- rapind 5y ago
  Unless you're importing historical records...
  - bee_rider 5y ago
    It seems likely that this is an issue with the code specifically, rather than the encoding of the files, based on the fact that they managed to roll out a fix pretty quickly.
    - rapind 5y ago
      I agree, but parent was responding to a more general comment of "Why is anyone using two-digit years anywhere at all?".
- cm2187 5y ago
  Well clearly they didn’t even seem to expect this code to be in use in 2022!
- smnrchrds 5y ago
  > it's quite unlikely this code will be in use in 78 years Famous last words.
  - perl4ever 5y ago
    I know of a system that uses "1/1/2099" everywhere an "infinity" date is needed. The problem with fixing it, is nobody thinks it will be their problem.
    - soared 5y ago
      My employer uses the year 2041 for infinity. It will be a truly massive disaster when that year arrives. There is tens of millions of dollars of advertising spend that is paused until “infinity”.
      - grishka 5y ago
        Whenever advertising stops working, the world becomes a better place.
        KETHERCORTEX 5y ago
        As far as I understood, according to soared's comment, a lot of advertising campaigns will _start again_ in 2041.
    - taneq 5y ago
      Realistically these particular people are right though.
Jenk 5y ago
Double edged sword.. if they were to use 4 digit numbers, they couldn't use int32 to store YYYYMMDDHHMM. But.. they wouldn't be able to use int32 and therefore wouldn't have had this bug. :)
- fendy3002 5y ago
  Why not using unix timestamp though? Is it cause they're MS?
  - munchler 5y ago
    Unix timestamp is hardly better, due to the Year 2038 problem. I think the only truly robust solution is to use a 64-bit integer instead.
    - mohaine 5y ago
      time_t solved the 2038 problem a long time ago
      - kristiandupont 5y ago
        ...not according to Wikipedia: https://en.wikipedia.org/w/index.php?title=Time_t&oldid=450752800#Implementation https://en.wikipedia.org/w/index.php?title=Time_t&oldid=4507...
      - baq 5y ago
        if you recompile the world, it did...
  - zarzavat 5y ago
    There's a difference between timestamps and dates. For instance Christmas Day is on 2022-12-25, but it doesn't have any particular time stamp as that depends on which time zone you are in. If you are making a calendar app, you want to store dates and not timestamps as, e.g. if I have a flight to another country then have an appointment at 9am, that 9am should be in the time zone of wherever I am physically present, which the calendar doesn't necessarily know. Storing as an integer is compact and allows for easy comparison. It's a clever hack, but they should have used 64 bit, or at least a u32!
teh_klev 5y ago
> Do people learn nothing from their past mistakes? I kinda feel you've never worked with a large code base or database that has a legacy going back 25+ years...older than many of the commentators on this thread. Not all of the data types used might have been obvious in their "danger", especially in ancient code. Sure you could run some analysis over the code, but can that analyser determine from a #def or variable name the true intent of the value being stored? I wrote an application for a customer in 1986, and stone me, they were still running it in a DOSBOX emulator in 2004. Lucky for me dates weren't important.
quench 5y ago
I am thinking this could be like DNS serial numbers. Possibly the code was written with a integer serial number (ok using signed is wrong) but then someone else thinks to make things easier for humans we will use this date format for the serial. Its quite possible that was never in the spec given to the programmer. DNS serial numbers are 32 bit unsigned and the convention is to use YYYYMMDDNN So this _convention_ breaks in year 4295, or if someone forgot to put unsigned 2148. It is only a convention though DNS only cares that the serial increases.
jks 5y ago
> Why is anyone using two-digit years Because with four-digit years this kind of date would never have fit into a signed 32-bit integer. Incidentally, this shows that the timestamp was taken into use after Y2K, since none of the pre-millennium years would have fit.

Why is anyone using two-digit years anywhere at all? This approach has already caused a lot of trouble 22 years ago. Do people learn nothing from their past mistakes?

btgeekboy 5y ago

Because these files aren't going backward in time, and it's quite unlikely this code will be in use in 78 years.

rapind 5y ago
Unless you're importing historical records...
- bee_rider 5y ago
  It seems likely that this is an issue with the code specifically, rather than the encoding of the files, based on the fact that they managed to roll out a fix pretty quickly.
  - rapind 5y ago
    I agree, but parent was responding to a more general comment of "Why is anyone using two-digit years anywhere at all?".
cm2187 5y ago
Well clearly they didn’t even seem to expect this code to be in use in 2022!
smnrchrds 5y ago
> it's quite unlikely this code will be in use in 78 years Famous last words.
- perl4ever 5y ago
  I know of a system that uses "1/1/2099" everywhere an "infinity" date is needed. The problem with fixing it, is nobody thinks it will be their problem.
  - soared 5y ago
    My employer uses the year 2041 for infinity. It will be a truly massive disaster when that year arrives. There is tens of millions of dollars of advertising spend that is paused until “infinity”.
    - grishka 5y ago
      Whenever advertising stops working, the world becomes a better place.
      - KETHERCORTEX 5y ago
        As far as I understood, according to soared's comment, a lot of advertising campaigns will _start again_ in 2041.
  - taneq 5y ago
    Realistically these particular people are right though.

Jenk 5y ago

Double edged sword.. if they were to use 4 digit numbers, they couldn't use int32 to store YYYYMMDDHHMM. But.. they wouldn't be able to use int32 and therefore wouldn't have had this bug. :)

fendy3002 5y ago
Why not using unix timestamp though? Is it cause they're MS?
- munchler 5y ago
  Unix timestamp is hardly better, due to the Year 2038 problem. I think the only truly robust solution is to use a 64-bit integer instead.
  - mohaine 5y ago
    time_t solved the 2038 problem a long time ago
    - kristiandupont 5y ago
      ...not according to Wikipedia: https://en.wikipedia.org/w/index.php?title=Time_t&oldid=450752800#Implementation https://en.wikipedia.org/w/index.php?title=Time_t&oldid=4507...
    - baq 5y ago
      if you recompile the world, it did...
- zarzavat 5y ago
  There's a difference between timestamps and dates. For instance Christmas Day is on 2022-12-25, but it doesn't have any particular time stamp as that depends on which time zone you are in. If you are making a calendar app, you want to store dates and not timestamps as, e.g. if I have a flight to another country then have an appointment at 9am, that 9am should be in the time zone of wherever I am physically present, which the calendar doesn't necessarily know. Storing as an integer is compact and allows for easy comparison. It's a clever hack, but they should have used 64 bit, or at least a u32!

teh_klev 5y ago

> Do people learn nothing from their past mistakes? I kinda feel you've never worked with a large code base or database that has a legacy going back 25+ years...older than many of the commentators on this thread. Not all of the data types used might have been obvious in their "danger", especially in ancient code. Sure you could run some analysis over the code, but can that analyser determine from a #def or variable name the true intent of the value being stored? I wrote an application for a customer in 1986, and stone me, they were still running it in a DOSBOX emulator in 2004. Lucky for me dates weren't important.

quench 5y ago

I am thinking this could be like DNS serial numbers. Possibly the code was written with a integer serial number (ok using signed is wrong) but then someone else thinks to make things easier for humans we will use this date format for the serial. Its quite possible that was never in the spec given to the programmer. DNS serial numbers are 32 bit unsigned and the convention is to use YYYYMMDDNN So this _convention_ breaks in year 4295, or if someone forgot to put unsigned 2148. It is only a convention though DNS only cares that the serial increases.

jks 5y ago

> Why is anyone using two-digit years Because with four-digit years this kind of date would never have fit into a signed 32-bit integer. Incidentally, this shows that the timestamp was taken into use after Y2K, since none of the pre-millennium years would have fit.