TIL that we can't know for sure the timestamp of now + some time span greater than 6 months.
Unix time is bad and needs replacement, not UTC
71–80 of 96 posts
Re: Unix time is bad and needs replacement, not UTC
#72Earlier quoted context omitted.
Having multiple time zone databases to sync and manage sounds like even worse idea. ID, well, it saves a tiny bit of space but honestly I don't think it is worth it if you're already storing info about timezone as text. If you're storing it in binary form you can convert the name to DB entry on save/display
My point is, Timezone-Names alone are not completely reliable. They only name the location, but not the political or historical situation of this location. Take Europe/Berlin for example, the city was once divided in two parts, and is now in a country which is changing timezone twice a year. With a location, you can only communicate to use the rules valid today, not rules which were valid at some point in the past, o…
And parts of Mexico used to be the same timezone as Los Angeles but then daylight savings time changed and the city you referenced has to change.
There’s no way to look at America/Los Angeles and know if that is California or Oregon, and if Oregon were to give up daylight savings time you’d have a problem.
Re: Unix time is bad and needs replacement, not UTC
#73This 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,…
It's fairly unusual to have a system where people can write timestamps in arbitrary timezones. Most of the time there's a suitable context where a timezone just makes sense
For example, in a booking system the timezone will be associated with the venue or the destination.
In a scheduler for a trading system certain timestamps (start, stop time etc) will be the timezone of the trading venue.
For past events (logging) UTC essentially always makes sense.
Re: Unix time is bad and needs replacement, not UTC
#74TIL that we can't know for sure the timestamp of now + some time span greater than 6 months.
You cannot know the delta, but the interpretation of a timestamp set 6 months in the future can be unambiguous
E.g. "27th March 2023 19:00 Europe/London" is not ambiguous
Re: Unix time is bad and needs replacement, not UTC
#75I hope that, when they redefine UTC, they define a new name for it. UTC has been the same timescale since it started; the history of redefinitions of GMT is a horror-story. I guess what I'm really saying is that UTC-without-LS won't be UTC; rather, we'd declare that the new universal civil-time timescale is to be UTC-without-LS. You could carry on computing old-fashioned UTC after the transition; but one wouldn't gen…
Leap seconds are determined manually, though, so it seems like there's no practical difference other than UTC's error from solar time going out of spec?
Re: Unix time is bad and needs replacement, not UTC
#76This 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 ; )
Speed relative to what?
Re: Unix time is bad and needs replacement, not UTC
#77Can 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.
60mins offset is fine¹. We have this all the time with timezones. But imagine investigating and outage or scheduling an automated event when you have to make sure and communicate with non-technical folks that your graph / setting etc is off by 5:23 minutes.
The OP proposal does say UTC should be used when representing time to end users, but in practice there is going to be blurry lines.
¹TBH, still confusing enough to introduce quite a bit of friction when comparing graphs etc for outages.
Re: Unix time is bad and needs replacement, not UTC
#78I wonder how bad of a timeformat would be just a bitfield struct with all of the parts(year/month/day/hour/minute/second/usec) broken out to separate fields. It should fit quite well to 64bits, so you could pass it along as an opaque 64bit integer value.
Re: Unix time is bad and needs replacement, not UTC
#79I hope that, when they redefine UTC, they define a new name for it. UTC has been the same timescale since it started; the history of redefinitions of GMT is a horror-story. I guess what I'm really saying is that UTC-without-LS won't be UTC; rather, we'd declare that the new universal civil-time timescale is to be UTC-without-LS. You could carry on computing old-fashioned UTC after the transition; but one wouldn't gen…
Since the French-speaking world has started to acknowledge that English is the modern lingua franca, perhaps we could now reach agreement to call the new system UCT for "Universal Coordinated Time".
Re: Unix time is bad and needs replacement, not UTC
#80I hope that, when they redefine UTC, they define a new name for it. UTC has been the same timescale since it started; the history of redefinitions of GMT is a horror-story. I guess what I'm really saying is that UTC-without-LS won't be UTC; rather, we'd declare that the new universal civil-time timescale is to be UTC-without-LS. You could carry on computing old-fashioned UTC after the transition; but one wouldn't gen…
This is effectively just an agreement to _stop_ redefining UTC every couple of years.