The Unix timestamp will begin with 16 this Sunday • Hacker News Board

Re: The Unix timestamp will begin with 16 this Sunday

#211

Post by tgsovlerkhgsel » Sun, Sep 13, 2020, 10:56 PM UTC

withinboredom wrote: post #96

tgsovlerkhgsel wrote: post #57

Earlier quoted context omitted.

With Earth's day length becoming irrelevant, the 24 hour clock becomes irrelevant too, and the length of the sleep cycle may shift. We could eventually arrive at stardates with one starday being 100000 seconds. Of course, that would be just as arbitrary as simply keeping the 24 hours of 60 minutes each.

Humans have a remarkable circadian rhythm that does a pretty good job at defining a day as “24 hours.”

To my knowledge, once you take the sun away, it tends to drift more towards 25 or 26 hours. And that's in humans who experienced the externally imposed 24 hour cycle for decades before participating in a short experiment, not potential spacefarers born onboard of stations or ships.

Re: The Unix timestamp will begin with 16 this Sunday

#212

Post by ncmncm » Wed, Sep 16, 2020, 1:36 AM UTC

shakna wrote: post #197

enedil wrote: post #188

Earlier quoted context omitted.

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

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.

Re: The Unix timestamp will begin with 16 this Sunday

#213

Post by shakna » Wed, Sep 16, 2020, 5:22 AM UTC

ncmncm wrote: post #212

shakna wrote: post #197

Earlier quoted context omitted.

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.

Re: The Unix timestamp will begin with 16 this Sunday

#214

Post by nineteen999 » Thu, Sep 17, 2020, 10:41 PM UTC

dripton wrote: post #98

iso1210 wrote: post #59

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

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.