Hacker News Reader

Comment by iso1210 | Hacker News Reader

I remember staying up late (UK) at the Billenium (2:46 AM Sunday Sep 9th 2001), thinking that was bound to be the most newsworthy event of the week, watching the seconds tick past on a "while(sleep 1); do date" loop, with slashdot in one window, IRC in another, all running on an enlightenment window manager.

500M seconds later I was in Washington DC in a hotel, watching it tick up on an rxvt on my laptop, with HN in a window.

Who knows where I'll be in 2033, hopefully not in Europe as I'll be too old for night shifts, but wherever I am, I suspect it will have a bash prompt.

View on HN

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.

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)

"A society grows great when old devs allocate timestamps whose higher bits they shall never set."

Why will PIC's fail sooner? (and which ones, 8, 16 or 32bit?)

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

Thanks - so seems it's an issue with their library, rather than something to with PIC's per se.

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.

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.

What on earth is that good for? Seems like an extreme niche.

Making time an unsigned 32 would break any code that computes a difference of times.

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.

> 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;
    }

We're not talking about C, were talking about how it works on the computers.

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.

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.

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.

There are exactly zero undefined behaviors around operations on unsigned integer types in C or in C++.

To get meaningful results may require some care, but the languages provide everything needed to exercise such care.

Perhaps you missed my earlier comment.

> Except signed overflow invoking Undefined Behaviour in any C compiler, whereas unsigned overflow does not.

We aren't talking about unsigned integer types. We're talking about the behaviour of signed integer types.

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...

---

Link to 1400000000 thread:

https://news.ycombinator.com/item?id=7736739

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

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.

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.

> a "while(sleep 1); do date" loop,

There's always "xclock -d -update 1 -strftime %s -face Inconsolata-190:bold "

You could at least give the event some proper gravitas by using Comic Sans instead.

> I remember staying up late (UK) at the Billenium (2:46 AM Sunday Sep 9th 2001)

Inconsolata wasn't released until 2006.

https://en.wikipedia.org/wiki/Inconsolata

Why not just `watch date` ?

watch updates every 2 seconds by default.

`watch -n1 date` will update every second.

Upvoting for Inconsolata.

Hah nice, I remember doing that too! At the time I thought it was important to keep the irc log, which I've just dug up and thrown up on pastebin. I don't actually remember which network this was (EFNet maybe?)

> 03:46:49 -crier- THE BILLENNIUM HAS ARRIVED!!!!! Uh, you might want to play auldlangsyne.wav. YAAAAAAAAAAAAAAAYYYYYY!

more at https://pastebin.com/71H7eR8r

For some reason the billennium arrives at 3:46:49, which doesn't make sense - I wasn't in UTC+2, and anyway this should've been at 01:46:40am UTC (40 seconds past the minute, not 49 seconds). Most likely reason is simply that my local machine's clock was wrong.

Sounds a bit like leap seconds, except there were 22 leap seconds before 2001.

I’m currently on an iPhone 7S. I’ve got a mosh session open to a remote raspberry pi 4B (time looks right), bash shell, “while(sleep 1); do date +%s”, running in Blink SSH while I read HN cause I couldn’t sleep. Have an alarm set for 12:26 UTC so I can grab that screenshot. Following along with you :)

I remember holding a similar billionth second party in Soda Hall (Wozniak Lounge) at Berkeley as an undergrad. Never realized how close that was before 9/11.

(guenine curiosity)

Why do you wait for these events ? Myself I consider these to be complete non-events.

For the same reason people wait for midnight on new year.

It's an arbitrary thing people do for fun.

it's like any holyday, it's a rendezvous for the community that recognizes it. it strengthens the social bonds

You got downvoted for this question but it’s such a great question in this context because like the UNIX epoch, the answer is arbitrary :)

Incidentally, I guess the windows/NT epoch started in 1601.

Reply on news.ycombinator.com