Live data from Hacker News

Insane complexity of calendrically correct date and time operations

yourcalendricalfallacyis.com

61–70 of 146 posts

Re: Insane complexity of calendrically correct date and time operations

#61
From the list: All the important years are four digits long

This left out the Long Now Foundation's advocacy for five-digit years to deal premptively with the Y10K bug. And, less tongue-in-cheek, to promote a view of time that is not conventional in this day and age.

Re: Insane complexity of calendrically correct date and time operations

#63

From the list: All the important years are four digits long This left out the Long Now Foundation's advocacy for five-digit years to deal premptively with the Y10K bug. And, less tongue-in-cheek, to promote a view of time that is not conventional in this day and age.

https://www.youtube.com/watch?v=czgOWmtGVGs

Re: Insane complexity of calendrically correct date and time operations

#66
post #4
post #2

Is it true that Unix time is as simple as it seems? Is there exactly one second between adjacent integers? Do all Unix time values occur only once simultaneously around the world?

What you want is probably TAI [1], Unix Time has leap seconds. [1] https://en.wikipedia.org/wiki/International_Atomic_Time

Or GPS time which is UTC w/o the leap seconds

Re: Insane complexity of calendrically correct date and time operations

#70

"False. The UNIX epoch is January 1, 1970 in UTC, but is Dec 31, 1969 in Los Angeles." This isn't specific to Los Angeles, right? It's just referring to the fact that anyone with a negative UTC offset would see an epoch date of Dec 31, 1969 in their local time (I hope).

Hm. No. The UNIX epoch is in UTC, so it's always January 1, 1970. The tick (at this moment: 1537511644) is always relative to January 1, 1970. The timezone (TZ) only comes into it when that epoch time is translated to a local time with 'date' and other tools.
Post reply on HN