5 ms·

A former employer's telephony software had a 9-character intstring field for the Unix timestamp, so there was a bug when it rolled over to 1000000000 in 2001.

A former employer's telephony software had a 9-character intstring field for the Unix timestamp, so there was a bug when it rolled over to 1000000000 in 2001. Pretty rare, I think. Unix timestamps back then were usually 32-bit ints, so good until 2038. And hopefully they'll be 64 bits everywhere that matters well before 2038.

ncmncm 6y ago
Or unsigned 32 bits, which takes us to 2106. Almost all things that have a timestamp leave you in no doubt which 136-year period they were taken in. For those, 32 bits is plenty.
- MatthiasWandel 6y ago
  Making time an unsigned 32 would break any code that computes a difference of times.
  - dragontamer 6y ago
    Not really. Addition and subtraction don't care about unsigned vs signed status, because overflow is identitcal in both cases. Think of an odometer for a car with 999999 as its max number. 999,999 is equivalent to -1. So 500 + 999999 == 499 on the odometer. A 32-bit register is simply a binary odometer, so the above concept happens with bits. In "signed int", we print the number "999999" as "-1". With "unsigned int", we print the number "999999" as "999999". They are one-and-the-same. The only difference is your print() function. ----- Multiplication and division change however. Your compiler tracks signed/unsigned status for idiv vs div, or mul vs imul instructions. -------- With that being said: I think 64-bits is fine. Most computers these days are 64-bits, and those 4-extra bytes aren't very costly. Standard compression algorithms, like GZip, do a good job of finding those redundant bits and shrinking things down.
    - shakna 6y ago
      > Addition and subtraction don't care about unsigned vs signed status, because overflow is identitcal in both cases. Except signed overflow invoking Undefined Behaviour in any C compiler, whereas unsigned overflow does not. This invokes undefined behaviour: foo(int x) { return x + 1 > x; }
      - enedil 6y ago
        We're not talking about C, were talking about how it works on the computers.
        labawi 6y ago
        Many if not most of the embedded/long term systems are implemented in C. If a variable is declared signed, overflowing cases may and often are "optimized" away. IIUC, GP's foo() would likely be optimized to { return true; }, and so would similar timestamp overflow checks.
        deleted 6y ago
        [deleted]
        dragontamer 6y ago
        The post I responded to was the opposite: about turning "signed" code (which you declare is undefined) into "unsigned" code (which you declare is fully defined). Given this thread of subargument, making the difference between 32-bit unsigned numbers is MORE DEFINED than using signed integers. ------- IE: If your code was correct with "int timestamp", it will be more correct with "unsigned int timestamp". In any case, "int" or "unsigned int" based timestamp manipulation wouldn't be like the code you suggested, but instead "int difference = x - y". In the signed integer case, "difference" is (conceptually) negative, while in the unsigned integer case, "difference" is guaranteed to have overflow. Both cases are conceptually correct with regards to the difference of timestamps.
        shakna 6y ago
        But because the behaviour is undefined, it doesn't matter how the computer would handle it, because the compiler is free to rework it into any arbitrary sequence of instructions, including removing it altogether.
- _kst_ 6y ago
  Making time_t unsigned would break the ability to refer to times before 1970. Existing code that deals with 32-bit timestamps almost universally assumes that (time_t)0 is 1970-01-01 00:00:00 UTC. Updating that code to guess a different epoch would be more work (with more inevitable bugs) than keeping a fixed epoch and using 64 bits. It's already 64 bits (and signed) on a lot of systems.
  - monadic2 6y ago
    What on earth is that good for? Seems like an extreme niche.
    - deleted 6y ago
      [deleted]
slyall 6y ago
I posted this back when we hit 1400000000 in 2014 [1]: --- Openldap got hit by the billennium bug. I remember because we told our Noc to keep an eye open (Sunday afternoon where we were) and we started getting alerts that all LDAP replication was broken. https://www.openldap.org/lists/openldap-bugs/200109/msg00052.html https://www.openldap.org/lists/openldap-bugs/200109/msg00052... --- Link to 1400000000 thread: https://news.ycombinator.com/item?id=7736739 https://news.ycombinator.com/item?id=7736739
_kst_ 6y ago
We had a bug tracking system that malfunctioned starting at (time_t)1000000000 (3 days before 9/11). Apparently it converted the time_t value to a string and truncated it to 9 characters. Its concept of the current time jumped back to 1973-03-03 and advanced from there at 10% of the normal rate. The bug was corrected fairly quickly.
wongarsu 6y ago
I was involved in building a system using 32-bit ints as timestamps ten years ago. They are still sold, and since it's industrial equipment running on 16 bit microcontrollers I have every reason to believe most of them will still be around in 2038. I don't think I was at the only company doing this. Few people seem to care about issues that will happen after their retirement. Expect lots of industrial stuff to work just a bit worse around 2038 (and 2036, PIC microcontrollers fail a bit sooner)
- jkoudys 6y ago
  "A society grows great when old devs allocate timestamps whose higher bits they shall never set."
- hazeii 6y ago
  Why will PIC's fail sooner? (and which ones, 8, 16 or 32bit?)
  - wongarsu 6y ago
    I worked with the 16 bit PIC24f. I don't have the source handy to check, but according to a forum entry "The provided gmtime() actually fails earlier than 2038. The year wraps around when the time_t input goes beyond 0x7C55817F or Thu Feb 7 06:28:15 2036." [1] 1: https://www.microchip.com/forums/m522929.aspx https://www.microchip.com/forums/m522929.aspx
    - hazeii 6y ago
      Thanks - so seems it's an issue with their library, rather than something to with PIC's per se.
nineteen999 6y ago
This happened to the wu-imap server my employer was using at the time since they were running the maildir patches: http://www.davideous.com/imap-maildir/#updates http://www.davideous.com/imap-maildir/#updates The sort function couldn't handle the rollover so when we came in that day all our mailboxes had their email sorted in the wrong order, and it couldn't be fixed without the listed patch.

ncmncm 6y ago

Or unsigned 32 bits, which takes us to 2106. Almost all things that have a timestamp leave you in no doubt which 136-year period they were taken in. For those, 32 bits is plenty.

MatthiasWandel 6y ago
Making time an unsigned 32 would break any code that computes a difference of times.
- dragontamer 6y ago
  Not really. Addition and subtraction don't care about unsigned vs signed status, because overflow is identitcal in both cases. Think of an odometer for a car with 999999 as its max number. 999,999 is equivalent to -1. So 500 + 999999 == 499 on the odometer. A 32-bit register is simply a binary odometer, so the above concept happens with bits. In "signed int", we print the number "999999" as "-1". With "unsigned int", we print the number "999999" as "999999". They are one-and-the-same. The only difference is your print() function. ----- Multiplication and division change however. Your compiler tracks signed/unsigned status for idiv vs div, or mul vs imul instructions. -------- With that being said: I think 64-bits is fine. Most computers these days are 64-bits, and those 4-extra bytes aren't very costly. Standard compression algorithms, like GZip, do a good job of finding those redundant bits and shrinking things down.
  - shakna 6y ago
    > Addition and subtraction don't care about unsigned vs signed status, because overflow is identitcal in both cases. Except signed overflow invoking Undefined Behaviour in any C compiler, whereas unsigned overflow does not. This invokes undefined behaviour: foo(int x) { return x + 1 > x; }
    - enedil 6y ago
      We're not talking about C, were talking about how it works on the computers.
      - labawi 6y ago
        Many if not most of the embedded/long term systems are implemented in C. If a variable is declared signed, overflowing cases may and often are "optimized" away. IIUC, GP's foo() would likely be optimized to { return true; }, and so would similar timestamp overflow checks.
        deleted 6y ago
        [deleted]
        dragontamer 6y ago
        The post I responded to was the opposite: about turning "signed" code (which you declare is undefined) into "unsigned" code (which you declare is fully defined). Given this thread of subargument, making the difference between 32-bit unsigned numbers is MORE DEFINED than using signed integers. ------- IE: If your code was correct with "int timestamp", it will be more correct with "unsigned int timestamp". In any case, "int" or "unsigned int" based timestamp manipulation wouldn't be like the code you suggested, but instead "int difference = x - y". In the signed integer case, "difference" is (conceptually) negative, while in the unsigned integer case, "difference" is guaranteed to have overflow. Both cases are conceptually correct with regards to the difference of timestamps.
      - shakna 6y ago
        But because the behaviour is undefined, it doesn't matter how the computer would handle it, because the compiler is free to rework it into any arbitrary sequence of instructions, including removing it altogether.
_kst_ 6y ago
Making time_t unsigned would break the ability to refer to times before 1970. Existing code that deals with 32-bit timestamps almost universally assumes that (time_t)0 is 1970-01-01 00:00:00 UTC. Updating that code to guess a different epoch would be more work (with more inevitable bugs) than keeping a fixed epoch and using 64 bits. It's already 64 bits (and signed) on a lot of systems.
- monadic2 6y ago
  What on earth is that good for? Seems like an extreme niche.
  - deleted 6y ago
    [deleted]

slyall 6y ago

I posted this back when we hit 1400000000 in 2014 [1]: --- Openldap got hit by the billennium bug. I remember because we told our Noc to keep an eye open (Sunday afternoon where we were) and we started getting alerts that all LDAP replication was broken. https://www.openldap.org/lists/openldap-bugs/200109/msg00052.html https://www.openldap.org/lists/openldap-bugs/200109/msg00052... --- Link to 1400000000 thread: https://news.ycombinator.com/item?id=7736739 https://news.ycombinator.com/item?id=7736739

_kst_ 6y ago

We had a bug tracking system that malfunctioned starting at (time_t)1000000000 (3 days before 9/11). Apparently it converted the time_t value to a string and truncated it to 9 characters. Its concept of the current time jumped back to 1973-03-03 and advanced from there at 10% of the normal rate. The bug was corrected fairly quickly.

wongarsu 6y ago

I was involved in building a system using 32-bit ints as timestamps ten years ago. They are still sold, and since it's industrial equipment running on 16 bit microcontrollers I have every reason to believe most of them will still be around in 2038. I don't think I was at the only company doing this. Few people seem to care about issues that will happen after their retirement. Expect lots of industrial stuff to work just a bit worse around 2038 (and 2036, PIC microcontrollers fail a bit sooner)

jkoudys 6y ago
"A society grows great when old devs allocate timestamps whose higher bits they shall never set."
hazeii 6y ago
Why will PIC's fail sooner? (and which ones, 8, 16 or 32bit?)
- wongarsu 6y ago
  I worked with the 16 bit PIC24f. I don't have the source handy to check, but according to a forum entry "The provided gmtime() actually fails earlier than 2038. The year wraps around when the time_t input goes beyond 0x7C55817F or Thu Feb 7 06:28:15 2036." [1] 1: https://www.microchip.com/forums/m522929.aspx https://www.microchip.com/forums/m522929.aspx
  - hazeii 6y ago
    Thanks - so seems it's an issue with their library, rather than something to with PIC's per se.

nineteen999 6y ago

This happened to the wu-imap server my employer was using at the time since they were running the maildir patches: http://www.davideous.com/imap-maildir/#updates http://www.davideous.com/imap-maildir/#updates The sort function couldn't handle the rollover so when we came in that day all our mailboxes had their email sorted in the wrong order, and it couldn't be fixed without the listed patch.