Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Unix timestamp will begin with 16 this Sunday

unixtimestamp.com

Post reply on HN
Print view View original

151–160 of 214 posts

Re: The Unix timestamp will begin with 16 this Sunday

#151

Post by _kst_ »

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.

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.

Re: The Unix timestamp will begin with 16 this Sunday

#153

Post by slyall »

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.

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

Re: The Unix timestamp will begin with 16 this Sunday

#155

Post by wongarsu »

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.

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)

Re: The Unix timestamp will begin with 16 this Sunday

#156

Post by adtac »

robk wrote: post #79
susam wrote: post #21

It is going to be at 2020-09-13 12:26:40 UTC. Python: $ python3 -q >>> from datetime import datetime >>> datetime.utcfromtimestamp(1_600_000_000) datetime.datetime(2020, 9, 13, 12, 26, 40) GNU date (Linux): $ date -ud @1600000000 Sun Sep 13 12:26:40 UTC 2020 BSD date (macOS, FreeBSD, OpenBSD, etc.): $ date -ur 1600000000 Sun Sep 13 12:26:40 UTC 2020 All such dates (in UTC) until the end of the current century: $ pyth…

It made me feel better doing the math I'm likely to be alive for 3,000,000,000

depends on how apocalyptic Y2038 is :)

Re: The Unix timestamp will begin with 16 this Sunday

#157

Post by jkoudys »

wongarsu wrote: post #155
dripton wrote: post #98

Earlier quoted context omitted.

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 j…

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

Re: The Unix timestamp will begin with 16 this Sunday

#158

Post by noisy_boy »

wolfram74 wrote: post #17
Retr0spectrum wrote: post #9

There's a nice countdown here: https://epochconverter.com/countdown

I quite like the Mayan counting system, so I made a little module that does the conversion and makes SVG's, this[1] is the only thing I've used it for so far, though. [1] https://wolfram74.github.io/ArabIntToMayaInt/countdown.html

Reminds me of the countdown clock on predator's hand-mounted display in Predator[0]. Maybe they took inspiration from the Mayan counting system.

[0]: https://en.wikipedia.org/wiki/Predator_(film)

Re: The Unix timestamp will begin with 16 this Sunday

#159

Post by ramshorns »

quicklime wrote: post #133
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…

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,…

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

Re: The Unix timestamp will begin with 16 this Sunday

#160

Post by jasomill »

netmare wrote: post #90
nvrspyx wrote: post #38

Earlier quoted context omitted.

To add, Powershell: (Get-Date "1/1/1970").AddSeconds(1600000000).ToUniversalTime() or alternatively for your local time: (Get-Date "1/1/1970").AddSeconds(1600000000).ToLocalTime()

Heh... I've run into this bug myself recently. Get-Date '...' returns a DateTime object of Unspecified kind, i.e. neither Local nor Utc. By design, such objects are interpreted as Local by ToUniversalTime() and as Utc by ToLocalTime(). They essentially assume the inverse of themselves, for better or worse. Since the Kind property is readonly, to get the real UTC date you need: $naive = (Get-Date "1/1/1970").AddSecond…

Or, equivalently,

    $utc = [DateTimeOffset]::FromUnixTimeSeconds(16e8).UtcDateTime
Incidentally,

    PS> ($utc, (Get-Date -AsUtc '1/1/1970'), (Get-Date -AsUtc), (Get-Date)).Kind
    Utc
    Utc
    Utc
    Local
In your example,

    $naive.Kind -eq [DateTimeKind]::Unspecified
correctly, because no DateTimeKind was specified.

The peculiar behavior you observed with ToLocationTime and ToUniversalTime exists to avoid breaking changes in working[1] code written for versions of the .NET Framework before 2.0, where DateTime.Kind was introduced (as was DateTimeOffset, so ToLocationTime and ToUniversalTime should probably be deprecated).

[1] "Breaking" changes exist for already-broken code, e.g., in Framework 2.0 and later, the return values of ToUniversalTime and ToLocalTime have Kinds Utc and Local, respectively, so applying the same conversion to an already-converted value no longer has any effect.

Post reply on HN