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

181–190 of 214 posts

Re: The Unix timestamp will begin with 16 this Sunday

#181

Post by JdeBP »

BoppreH wrote: post #46
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.

There is a very good reason to eventually abandon it: leap seconds. Unix time goes back one second whenever there is a leap second on Earth. It's extremely weird and IMHO completely ruins the purpose of a timestamp, but it's a compromise for backwards compatibility, since Unix time was created before leap seconds. This hack ensures that the number of seconds in a day remains fixed, an assumption of many systems at th…

Leap seconds were introduced in 1972. The time_t that you are thinking of was invented somewhere around 1974, according to Unix historians.

Ironically, your kernel measures TAI time perfectly happily if unmolested, as that always ticks once for every SI second (ignoring oscillator drift). No slewing. No smearing. No stepping.

Re: The Unix timestamp will begin with 16 this Sunday

#182

Post by ithkuil »

throw0101a wrote: post #82
divbzero wrote: post #55

Earlier quoted context omitted.

Little is known about “Unix” but it is believed he or she was a charismatic spiritual leader who brought hope, healing, and comfort to countless humans on Earth and inspired numerous disciples including “BSD”, “Linux”, and “System V”.

> Little is known about “Unix” but […] As opposed to eunuchs.

Well, isn't Unix a castrated Multics?

Re: The Unix timestamp will begin with 16 this Sunday

#183

Post by JdeBP »

bitpow wrote: post #113
sltkr wrote: post #89

Earlier quoted context omitted.

Yes, but the point is that the UNIX timestamp doesn't count the the number of seconds elapsed since January 1, 1970. It counts 86400 seconds per day, regardless of how many seconds the day actually has (which can vary due to leap seconds).

Is this accurate though? Isn’t the number of seconds since 1970 absolute, and it’s up to the library generating the Gregorian date to take into account leap seconds? I suppose if these libraries are not taking into account leap seconds, then the actual rollover will be a few seconds earlier (or later?) than what we think.

Your time_t isn't the true number of SI seconds since the Epoch. It's that number, mucked around 27 times so far. Instead of leaving their kernels to count one tick per SI second (ignoring oscillator drift) many people slew, step, or smear their seconds count every time that there is a leap second.

Go and read about "right" versus "posix" timezones.

* https://unix.stackexchange.com/a/294715/5132

Re: The Unix timestamp will begin with 16 this Sunday

#184

Post by JdeBP »

m-p-3 wrote: post #60
BoppreH wrote: post #46

Earlier quoted context omitted.

There is a very good reason to eventually abandon it: leap seconds. Unix time goes back one second whenever there is a leap second on Earth. It's extremely weird and IMHO completely ruins the purpose of a timestamp, but it's a compromise for backwards compatibility, since Unix time was created before leap seconds. This hack ensures that the number of seconds in a day remains fixed, an assumption of many systems at th…

Or lets say we colonize a planet with a significant time dilation (ie near a supermassive blackhole), how do you deal with this? Who has the canonical time?

You don't have to go to science fiction for this. Science fact will do. On Earth, with Atomic Time, we already have to account for general relativistic effects. Doco from the BIPM (the SI Brochure) already talks about accounting for them across the sizes of the measuring devices.

Re: The Unix timestamp will begin with 16 this Sunday

#185

Post by JdeBP »

dodobirdlord wrote: post #178
numpad0 wrote: post #136

Earlier quoted context omitted.

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.

... unless it's the system clock in Linux, with the hardware RTC set to be interpreted as local time, and one is watching a system boot on a machine that is set up as east of the Prime Meridian (i.e. the hardware RTC is ahead of UTC). (-:

* https://unix.stackexchange.com/a/600490/5132

Re: The Unix timestamp will begin with 16 this Sunday

#186

Post by JdeBP »

kazagistar wrote: post #80
komali2 wrote: post #58

Earlier quoted context omitted.

Yea, but if we're going to use a "number of seconds since ..." Type system like Unix time, SOMEONE has to be the origin point, so I don't think this is a knock against Unix time.

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…

Well we already have to keep track of the size and shape of Earth. Go and read the SI Brochure from the BIPM. Local measurements by atomic clocks on Earth have to be weighted according to how far they are from a reference surface of equal gravitational potential. There's a publication named Circular T that comes out every 5 days.

You don't need science fiction for this.

* https://www.bipm.org/en/bipm-services/timescales/time-ftp/Ci...

Re: The Unix timestamp will begin with 16 this Sunday

#187

Post by JdeBP »

fsckboy wrote: post #50

I'll be waiting to C-elebrate for 1,610,612,736* which is 122 days later or January 13th plus or minus a day or two (I was lazy). * 0x6000 0000

    % printf "@40000000%08x%08x %#xs SI since the Unix v4 Epoch\n" \
      0x6000000A 0 0x60000000 |
      TZ=right/UTC tai64nlocal
    2021-01-14 08:25:09.000000000 0x60000000s SI since the Unix v4 Epoch
    %

Re: The Unix timestamp will begin with 16 this Sunday

#188

Post by enedil »

shakna wrote: post #161
dragontamer wrote: post #145

Earlier quoted context omitted.

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

> Addition and subtraction don't care about unsigned vs signed status, because overflow is identitcal in both cases. Except signed overflow invoking Undefined Behaviour in any C compiler, whereas unsigned overflow does not. This invokes undefined behaviour: foo(int x) { return x + 1 > x; }

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

Re: The Unix timestamp will begin with 16 this Sunday

#190

Post by londt8 »

wwright wrote: post #180
larkeith wrote: post #174

Earlier quoted context omitted.

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

ISO8601 is quite large, they probably don't want to ship that big standard library modules which would parse 100% of ISO8601
Post reply on HN