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

141–150 of 214 posts

Re: The Unix timestamp will begin with 16 this Sunday

#141

Post by X6S1x6Okd1st »

ericbarrett wrote: post #77
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…

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 .

I found Go's quite good as well

Re: The Unix timestamp will begin with 16 this Sunday

#142

Post by remram »

ncmncm wrote: post #116
kazagistar wrote: post #80

Earlier quoted context omitted.

Its unfortunate to use an accelerating reference (earth rotating sun, sun rotating galaxy, galaxy intermixing with andromeda) because it requires you to awkwardly keep track of the astronomy of earth for timekeeping. Instead, you would want a standardized reference time frame, say, "unix time assuming earth in 1970 never experienced any acceleratiom or dilation" and then everyone, including earth people, would track…

Quasar time plus position, motion vector, and acceleration vector should be a good enough reference for anybody.

You can't do math on that directly though. You'd still need to convert them to a common reference frame for comparison.

Re: The Unix timestamp will begin with 16 this Sunday

#143

Post by aftbit »

ncmncm wrote: post #115
moonbug wrote: post #92

Earlier quoted context omitted.

Fire, then Deepness, then stop.

Or Fire , then The Peace War . Maybe dip into True Names , followed by Shockwave Rider by John Brunner. Many people didn't like Deepness much. But the sequel to Fire, Children of the Sky , was interesting.

I quite enjoyed Rainbow's End as well.

Re: The Unix timestamp will begin with 16 this Sunday

#144

Post by MatthiasWandel »

ncmncm wrote: post #111
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.

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 an unsigned 32 would break any code that computes a difference of times.

Re: The Unix timestamp will begin with 16 this Sunday

#145

Post by dragontamer »

MatthiasWandel wrote: post #144
ncmncm wrote: 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 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.

Re: The Unix timestamp will begin with 16 this Sunday

#146

Post by jessaustin »

aftbit wrote: post #143
ncmncm wrote: post #115

Earlier quoted context omitted.

Or Fire , then The Peace War . Maybe dip into True Names , followed by Shockwave Rider by John Brunner. Many people didn't like Deepness much. But the sequel to Fire, Children of the Sky , was interesting.

I quite enjoyed Rainbow's End as well.

There's an extra apostrophe there... this is addressed toward the end of the novel.

Re: The Unix timestamp will begin with 16 this Sunday

#147

Post by ak217 »

ncmncm wrote: post #115
moonbug wrote: post #92

Earlier quoted context omitted.

Fire, then Deepness, then stop.

Or Fire , then The Peace War . Maybe dip into True Names , followed by Shockwave Rider by John Brunner. Many people didn't like Deepness much. But the sequel to Fire, Children of the Sky , was interesting.

Personally I found Fire and Deepness to be equally, profoundly, good. Haven’t found any other Vinge books to be nearly as good.

Re: The Unix timestamp will begin with 16 this Sunday

#148

Post by canofbars »

jezze wrote: post #37

When we one day become a space faring civilization we will probably stop using the gregorian calendar because why would you use that on say Mars? But there really is no reason to get rid of the unix timestamp as a measure of time and this measure may stay around for a long time. This may mean that people in the future might consider 1970 as year zero where modern civilization began.

Wont there be issues using the same time on different planets since time speed is not constant?

Re: The Unix timestamp will begin with 16 this Sunday

#149

Post by MayeulC »

lozf wrote: post #114
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 "while(sleep 1); do date" loop, There's always "xclock -d -update 1 -strftime %s -face Inconsolata-190:bold "

Why not just `watch date` ?

Re: The Unix timestamp will begin with 16 this Sunday

#150

Post by _kst_ »

ncmncm wrote: post #111
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.

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.

Post reply on HN