201–210 of 456 posts
Earlier quoted context omitted.
Datetime storage would consist of two explicit parts: one free from leap seconds (similar to the raw timestamp you get from a GPS receiver), and description of when leap seconds happen, so that you can transform the leap-second-free timestamp into UTC. Feels like a more robust way in principle to me.
So like a CRDT for time
Earlier quoted context omitted.
Indeed; the converse would be to add (or remove) micro-leapseconds in order to keep accurate time. That way it would happen so often that the code would get tested and we'd have working implementations (maybe we could fix the traditional Apple issues with leap years at the same time).
I’m pretty sure we would get bugs whenever the accumulated micro-leapseconds would reach a full second.
The point still stands though - common problems have tested code, uncommon/rare problems rarely have battle-hardened solutions.
Earlier quoted context omitted.
Yeah you are right, when a leap second is introduced it becomes 23:59:60 (monotonic) in utc, while with unix-time a normal way to handle it is to repeat 23:59:59 twice (non-monotonic).
Leap seconds can be negative.
Positive leap seconds are monotonically increasing in UTC, where you get 23:59:60 between 23:59:59 and 00:00:00, but not in typical implementations of unix time where 23:59:59 repeats, and with milliseconds you go (breifly) 58.999 -> 59.0 -> 59.999 -> 59.0 -> 59.999 -> 0.0
If you're only counting seconds, then both UTC and unixtime are always monotonically increasing.
Hot take… Storing anything as UTC was a mistake and we should be using TAI for all storage and computation, only transforming into more human friendly formats for display to end users. This never needed to be a problem except we decided to make it harder to use TAI than UTC and so everything got built up off the backs of legacy bios level hardware supported UTC style clock behaviour, when we should have been using TA…
You've made a very good point. All new software/systems I build will use TAI64. As an industry we should just push this move ourselves
Earlier quoted context omitted.
The moral of the story is that laziness is a virtue. Think of all the time that could have been saved, had you had no plans like your partners ;)
Think of all the time that could be better appropriated than on fintech in general. Seems like such a waste of resources siccing a bunch of computers against each other in a zero sum game of stock arbitrage. I will admit some of the stuff tech comes out of it is cool on its own at least.
Earlier quoted context omitted.
The drift is sufficiently slow that you can fix it with a "leap hour" when needed -- perhaps once every five thousand years. This could be handled for civil/local time via an adjustment in the timezone definitions (something which happens a few times a year today), leaving the underlying UTC timebase unchanged.
The main difficulty is convincing Greenwich to not be utc+0 anymore.
Earlier quoted context omitted.
Why bother? A calendar year is 365.242 days long... time is already off by about 3/4 of a day the year before a leap year, what does adding a second here or there really do?
Time is not off by about 3/4 of a day, calendar is. And hardly many people care about planet's position relative to the Sun (on the orbit) — I mean, they can, if it is important for they occult rituals or something, but probably they learned to work with it over the centuries already. Earth's rotation relative to the Sun is whole another deal.
So we make things worse for humans in order to make it easier for computers? Yah, one second doesn't matter, but it builds up. This: "Or we could even decouple our sense of time from the Sun entirely, to create a single world time zone in which different countries see the Sun overhead at different times of day or night." Shows that they are completely disconnect from human reality: "Science already doesn’t use local…
> Yah, one second doesn't matter, but it builds up. I don't think it's that big of a deal; do you really care what the perception of "11 in the morning" is for someone 1,000 years ago? This kind of thing is pretty cultural anyway, and a slow drift over a thousands of years doesn't really matter. The main reason we have the "new" Gregorian calendar is because of religious reasons, not because people were having huge p…
It just so happened that the religious authority in the West was able to make a significant change to the civil calendar which also happened to match the Church calendar, and it was adopted by all of Christendom, eventually even Asia and the four corners of the Earth have accepted it as universal and not so religious.
In 2015 I was working at a "fintech" company and a leap second was announced. It was scheduled for a Wednesday, unlike all others before which had happened on the weekend, when markets were closed. When the previous leap second was applied, a bunch of our Linux servers had kernel panics for some reason, so needless to say everyone was really concerned about a leap second happening during trading hours. So I was assig…
>I spent a month in the lab Do you mean at your desk? What is a lab in a fintech context?
Earlier quoted context omitted.
I'm not sure I support your "hot take" — it is hot and requires a lot of contemplation. But that's not the point, IMO. The point is, that there ALREADY EXIST both TAI and UTC. TAI is true monotonic (whatever it means in a relativistic universe) and doesn't make any compromises. UTC abolishes monotonicity in order to keep both the length of a second and the time relationship to the orbital rotation. They both work. Fo…
If you want to keep UTC matching the solar rotation, why do you specifically require leap seconds? Why not leap minutes? Or leap milliseconds? The choice of ±1 s as the acceptable error seems arbitrary.
So, to sum it up:
- TAI is a real thing, it has a concrete meaning, and it's "leap infinity".
- UT1 is a real thing, but is unusable in practice, and you could think of it as "leap ms"
- UTC until yesterday was a real thing, meaning time, which has seconds equal to TAI-seconds, but not drifting from UT1 for more than 0.9 s. Since today it's broken and I'm not sure what it even means anymore — I mean, not in practice, but "platonically".
- Nobody just introduced a standard that would mean "time with seconds equal to TAI-seconds, but not drifting from UT1 for more than 59 s" yet. I guess you could be the one to do it, but I'm not sure it would get a wide adoption.