Live data from Hacker News

The Unix timestamp will begin with 16 this Sunday

unixtimestamp.com

171–180 of 214 posts

Re: The Unix timestamp will begin with 16 this Sunday

#171
post #63

The crazy thing is there has only been 1.6 billion seconds since 1970. There have been more babies since 1970 than there have been seconds. Which is crazy. Back then, Earth's population was on 3.7 billion. Now it's 7.8 billion. That means that (ignoring deaths) 2.5 babies have been born for each unix second. Or roughly 1 baby every 400 milliseconds.

Linear vs quadratic growth.

Good point and great way to think about it. It would be weird if the number of seconds grew quadratically. I guess considering "particle interactions" and "light cone" the number of interactions among particles (and interactions among interactions) grows quadratically over time. I wonder how the universe doesn't end up with a backlog of information it hasn't yet processed. Maybe that's gravity/dark matter. :p ;) xx hehe

Re: The Unix timestamp will begin with 16 this Sunday

#172

The crazy thing is there has only been 1.6 billion seconds since 1970. There have been more babies since 1970 than there have been seconds. Which is crazy. Back then, Earth's population was on 3.7 billion. Now it's 7.8 billion. That means that (ignoring deaths) 2.5 babies have been born for each unix second. Or roughly 1 baby every 400 milliseconds.

Also crazy to think of, is: If you have a billion (i.e., 1E9) dollars, or any other currency, and you spend $86,400 dollars a day, it will take you more than 31 years and 8 months to spend the entire billion.

[deleted]

Re: The Unix timestamp will begin with 16 this Sunday

#173
post #150
post #111

Earlier quoted context omitted.

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.

Re: The Unix timestamp will begin with 16 this Sunday

#174

Earlier quoted context omitted.

The datetime package is one of the best things about Python, and dare I say one of the best general purpose calendar modules ever written. It’s just so practical .

It still can’t parse ISO8601 :(

`datetime.fromisoformat()`, as of 3.7 :D

Though `dateutil` is still recommended for most cases.

Re: The Unix timestamp will begin with 16 this Sunday

#176
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…

I can already hear people from 2033 celebrating 2b..

Re: The Unix timestamp will begin with 16 this Sunday

#177
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…

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

Re: The Unix timestamp will begin with 16 this Sunday

#178

Earlier quoted context omitted.

Looking at a clock from Earth through a telescope isn't as straightforward as you'd think. The image you see of that clock is actually light (photons) emitted from Earth, which will take a while to reach you - like, 1 year, if you're 1 lightyear away. During that year, Earth has moved on, maybe blew itself apart. But you can't even tell, because information can't reach you faster than light :) So you can only see Ear…

Yeah but can it ever go back, other than by backing off faster than the speed of light? If it can’t then it’s at least monotonic, even if it’s not rate constant

All observers observer all clocks to advance monotonically forward in time, regardless of their location or relative speed, unless the clock is moving at the speed of light. But the rate that each clock is observed to advance at depends on things like relative speed, acceleration, and the curvature of spacetime.

Re: The Unix timestamp will begin with 16 this Sunday

#179
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…

That's the point that your library's time_t reaches those values. But the point at which you will be 1.6Gs since the Unix v4 Epoch is in fact 27 seconds earlier, because your time_t hasn't counted the leap seconds over that period. To do that with Unix tools, you need to work with TAI timekeeping, not UTC, and remember that the (biased) zero point for TAI timekeeping is 10s before the Unix v4 Epoch.

    % jot - 10 20 | while read -r d 
    do 
       printf "@40000000%08x%08x %s00Ms SI since the Unix v4 Epoch\n" \
              "$d"00000010 0 "$d"
    done |
    TZ=right/UTC tai64nlocal
    2001-09-09 01:46:18.000000000 1000Ms SI since the Unix v4 Epoch
    2004-11-09 11:32:58.000000000 1100Ms SI since the Unix v4 Epoch
    2008-01-10 21:19:37.000000000 1200Ms SI since the Unix v4 Epoch
    2011-03-13 07:06:16.000000000 1300Ms SI since the Unix v4 Epoch
    2014-05-13 16:52:55.000000000 1400Ms SI since the Unix v4 Epoch
    2017-07-14 02:39:33.000000000 1500Ms SI since the Unix v4 Epoch
    2020-09-13 12:26:13.000000000 1600Ms SI since the Unix v4 Epoch
    2023-11-14 22:12:53.000000000 1700Ms SI since the Unix v4 Epoch
    2027-01-15 07:59:33.000000000 1800Ms SI since the Unix v4 Epoch
    2030-03-17 17:46:13.000000000 1900Ms SI since the Unix v4 Epoch
    2033-05-18 03:32:53.000000000 2000Ms SI since the Unix v4 Epoch
    %
Also, your figures for 0.0Gs and 0.1Gs are nonsense anyway.

Unix didn't adopt this Epoch and method of timekeeping until 4th Edition, somewhere in 1974 according to Unix historians. Yes, it's tricky to pin down the exact date of adoption. The Epoch was changed every year before then, as earlier versions of Unix measured time in 60ths of a second since the start of the year. This has made reconstructing Unix history from tape archives non-trivial. If you want to count seconds since the start of the first Unix Epoch, in 1st Edition, you have to count from the start of 1971. And no, that's not the same as how old Unix is.

(And yes, those values for 2023 onwards are somewhat speculative, as there will no doubt be more leap seconds.)

Re: The Unix timestamp will begin with 16 this Sunday

#180

Earlier quoted context omitted.

It still can’t parse ISO8601 :(

`datetime.fromisoformat()`, as of 3.7 :D Though `dateutil` is still recommended for most cases.

That parses a subset and is only guaranteed to be compatible with Python’s “.toisoformat()”. (I imagine it would be backwards compatible to expand it to cover all of ISO8601 and I can’t tell why they haven’t.)
Post reply on HN