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.
The Unix timestamp will begin with 16 this Sunday
171–180 of 214 posts
Re: The Unix timestamp will begin with 16 this Sunday
#172The 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.
Re: The Unix timestamp will begin with 16 this Sunday
#173Earlier 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.
Re: The Unix timestamp will begin with 16 this Sunday
#174Earlier 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 :(
Though `dateutil` is still recommended for most cases.
Re: The Unix timestamp will begin with 16 this Sunday
#175Re: The Unix timestamp will begin with 16 this Sunday
#176It 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…
Re: The Unix timestamp will begin with 16 this Sunday
#177Earlier 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…
Re: The Unix timestamp will begin with 16 this Sunday
#178Earlier 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
Re: The Unix timestamp will begin with 16 this Sunday
#179It 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…
% 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
#180Earlier quoted context omitted.
It still can’t parse ISO8601 :(
`datetime.fromisoformat()`, as of 3.7 :D Though `dateutil` is still recommended for most cases.