Please don't bite, but why not move the UTC merdian?
Unix time is bad and needs replacement, not UTC
31–40 of 96 posts
Re: Unix time is bad and needs replacement, not UTC
#32Earlier quoted context omitted.
I see leap seconds as regulatory capture by astronomers :D Basically it's convenient for them to have civil time (UTC) never more than 0.5s from UT1.
Astronomers don’t care, they already need like 5 different clocks. Also the allowable variance between UTC and ut1 is 0.9.
Exactly - and if astronomers don't care, what other reasons are there to require accurate synchronization of UTC (and civil time) with earth's rotation?
Re: Unix time is bad and needs replacement, not UTC
#33Can someone comment on the practical usefulness of having UTC stay strictly synchronized with the rotation of the Earth? Intuitively it should be synchronized, but giving it more thought it is not entirely obvious why; e.g. my current local time zone is more than half an hour off of local solar time, and that isn't really a practical problem, so if UTC would be, say, five minutes off of actual solar time in Greenwich…
> what issues does it cause for people?
Five minutes - no problem at all.
If the offset rose to 60 minutes, I know people complain bitterly twice a year when we change the clocks by an hour and they lose an hour of light for sports in the evening, or lose an hour of sleep. But with leapseconds taking ~0.5 seconds a year, that won't be a problem for a few thousand years.
Re: Unix time is bad and needs replacement, not UTC
#34Please don't bite, but why not move the UTC merdian?
why not move the UTC merdian?
You certainly mean to say the UTC nerdian, right? It's defined to cut through the median of all discussions around UTC, TAI, Unix timestamps and leap seconds that occur on HN and I see no reason to move it to another forum.
Re: Unix time is bad and needs replacement, not UTC
#35This is a good article, it's worth reading in full. It touches on the different use cases for different types of time/date storage but doesn't make it explicit enough that the is no "one size fits all" solution. It's true that internally a TIA timestamp is cleaner for storing a moment in time, but that is only half the issue. I like to think of it as a difference between physical time and human time. For engineering,…
I expect you’ll find that a single spot on earth can have multiple values of the current time, depending on who you ask.
For example, India, Pakistan, and China are each are in their own time zone, and (https://en.wikipedia.org/wiki/Jammu_and_Kashmir_(union_terri...) “Jammu and Kashmir is a region administered by India as a union territory and consists of the southern portion of the larger Kashmir region, which has been the subject of a dispute between India and Pakistan since 1947, and between India and China since 1962”
⇒ I expect there are events that are recorded to have happened at three different times, depending on who you ask.
https://en.wikipedia.org/wiki/List_of_territorial_disputes has many other territorial disputes, including ones between Canada and the USA (https://en.wikipedia.org/wiki/List_of_areas_disputed_by_Cana...), but most of them won’t be across time zones.
Also, there are other calendars in use than the Gregorian one. Most confusingly, some groups still use the Julian Calender.
Re: Unix time is bad and needs replacement, not UTC
#36This is a good article, it's worth reading in full. It touches on the different use cases for different types of time/date storage but doesn't make it explicit enough that the is no "one size fits all" solution. It's true that internally a TIA timestamp is cleaner for storing a moment in time, but that is only half the issue. I like to think of it as a difference between physical time and human time. For engineering,…
Given the findings of general relativity we might also wanna include the speed of the object in fractions of lightspeed ; )
Re: Unix time is bad and needs replacement, not UTC
#37Large cloud providers smear time. A day containing a leap second has the normal number of Unixtime "seconds" but each is 1/86400 too long. The inaccuracy this introduces is relevant to such a tiny tiny percentage of use cases; who already have to deal with the extreme complexities of time at this accuracy that everyone wins.
I find it difficult to believe there are use cases affected by this; given that NTP normally has an error window of some milliseconds, those use cases would never have worked.
Re: Unix time is bad and needs replacement, not UTC
#38There is an obvious need for time synchronized with the rotation of the Earth so leap seconds, or an equivalent mechanism, is also needed. The question is where to convert between linear time, more suited for computer systems, and Earth-synchronised time.
In terms of computer system design I'd say that the best is usually to convert as late as possible in a presentation layer and to use linear time internally everywhere.
Re: Unix time is bad and needs replacement, not UTC
#39Earlier quoted context omitted.
If Unix time ignored them, the conversion between timestamps and UTC would no longer be possible with just arithmetic operations. You'd need a list of leap seconds and take them into account. Now one can argue if this is better or worse than the current solution, but it's not without its tradeoffs.
Edit: My original comment is incorrect. Please read child comments. Original comment: Yes, to convert from UNIX time to UTC, you do need a list of leap seconds.
Others have already corrected you, but in case it makes it more concrete, here is the implementation of timegm() in musl (the libc used in Alpine Linux and some other Linux distributions). timegm() takes a time in UTC and converts it to Unix time.
http://git.musl-libc.org/cgit/musl/tree/src/time/timegm.c
http://git.musl-libc.org/cgit/musl/tree/src/time/__tm_to_sec...
You'll notice there is no handling or knowledge of leap seconds. (Leap years are handled, of course.)
Re: Unix time is bad and needs replacement, not UTC
#40This is a good article, it's worth reading in full. It touches on the different use cases for different types of time/date storage but doesn't make it explicit enough that the is no "one size fits all" solution. It's true that internally a TIA timestamp is cleaner for storing a moment in time, but that is only half the issue. I like to think of it as a difference between physical time and human time. For engineering,…
I expect you’ll find that a single spot on earth can have multiple values of the current time, depending on who you ask. For example, India, Pakistan, and China are each are in their own time zone, and ( https://en.wikipedia.org/wiki/Jammu_and_Kashmir_(union_terri... ) “Jammu and Kashmir is a region administered by India as a union territory and consists of the southern portion of the larger Kashmir region, which has…
True, and thats why it's important to have both the political time centre with a TZ database city, as well as coordinates as an options. They are both different things.
TZ database city covers the political time based on a political centre, and is future proof for that use case.
Coordinates cover changing political centres. If a country border moves but you need to specify a time that will update with any boundary changes this is the only way. The coordinates also don't have to match the location of the event, they are specifying the "human time" reference point.