101–110 of 135 posts
Earlier quoted context omitted.
100 seconds per minute, 100 minutes per hour, 20 hours a day. New seconds are 0.432 old seconds, or whatever ratio they need to make to quit leaping around.
Fun fact: the reason we use 60 seconds and 60 minutes is because of the Babylonians who used base-60. IIRC, it's also why we use 360° for a circle.
Earlier quoted context omitted.
TAI timestamps can unambiguously refer to times years in the future. You can subtract the TAI timestamp from the current time, set an alarm for that number of seconds and it will actually occur on cue . TAI timestamps don't refer unambiguously to UTC timestamps or calendar dates in the future, because the latter two depend on the variable rotation of the earth and (for zoned times) geopolitical whimsy. I don't see wh…
Think through your proposal to track all times in TAI and then convert them for display. What TAI time do you pick to represent the time that will be displayed as "00:00:00 on January 1, 2020"? Are you going to be okay with it changing to "23:59:58 on December 31, 2019" due to the geopolitical whimsy you mention? What if you just wanted it to represent the day "January 1, 2020"? Do you not use timestamps for anything…
> But updating all time conversion software (instead of just updating authoritative clocks) every time there's a leap second is ludicrous.
All time conversion software is already updated every time a government changes a time zone - by downloading the most recent tzdata. All software that needs second-level granularity is constantly updated, by synchronizing with NTP. There's nothing at all ludicrous about distributing leap second tables instead of mutilating the NTP time signal.
Earlier quoted context omitted.
Leap seconds are a change to the number of UTC epoch seconds.
> Leap seconds are a change to the number of UTC epoch seconds. UTC is different from epoch time. Epoch time by definition does not count leap seconds. https://en.m.wikipedia.org/wiki/Unix_time
It sounds like what it means is that Unix time counts the number of real, actual, by-the-clock seconds that have passed since the epoch. That would be logical. But what it actually means is that it counts the number of real, actual, by-the-clock seconds, minus the number of those those that have been designated "leap seconds".
That is to say, whenever a "leap second" occurs, the nice monotonic isotonic progress of unix time is mutilated by suddenly adding or removing 1 to the total count so far. That's what "does not count leap seconds" means, and sometimes even what "ignores leap seconds" means (which is of course even worse terminology).
My CDMA phone dropped service for a few minutes after the leap second. It's absurd that we continue to keep subjecting ourselves to these disruptions and the considerable amount of work that goes into handling leap seconds for the systems that aren't disrupted by them. Leap seconds serve no useful purpose. Applications that care about solar time care usually care about the local solar time, while UT1 is a 'mean solar…
While we're at it, can we get rid of daylight savings time too?
It's just so nice to get that extra bit of sunlight in the evening.
My CDMA phone dropped service for a few minutes after the leap second. It's absurd that we continue to keep subjecting ourselves to these disruptions and the considerable amount of work that goes into handling leap seconds for the systems that aren't disrupted by them. Leap seconds serve no useful purpose. Applications that care about solar time care usually care about the local solar time, while UT1 is a 'mean solar…
While we're at it, can we get rid of daylight savings time too?
Earlier quoted context omitted.
It's difficult to write bug-free code for events that happen very infrequently. Even more so when the distributed nature of the system makes effective testing under real-world conditions nearly impossible.
Yeah, that's exactly why Leap Day getting skipped every 4th year is such a disaster.
Earlier quoted context omitted.
It would seem much simpler to just use TAI for timestamps, and get civil datetimes from UTC. Why didn't people do this? Why use UTC for timestamps??
That doesn't seem simpler at all. - UTC timestamps can unambiguously refer to times years in the future; TAI timestamps cannot, because it is unknown how many seconds will be in each year. - Converting UTC timestamps to human-readable UTC times is simple modular arithmetic. A beginner in any programming language can do it. Converting TAI to UTC requires a lookup table, and it must be updated after the software is rel…
But for timestamps that can be used to obtain a time difference between them, TAI should be readily available to be used. Most timestamps are for figuring out time differences here on Earth and not relative to astrological signs, they are for knowing what came before what, etc. They are not for generating human-readable dates. It's silly that such a major use case is hardly implemented on major systems, and instead an unreliable Unix Time is used which can "at any moment" have the same second twice.
My CDMA phone dropped service for a few minutes after the leap second. It's absurd that we continue to keep subjecting ourselves to these disruptions and the considerable amount of work that goes into handling leap seconds for the systems that aren't disrupted by them. Leap seconds serve no useful purpose. Applications that care about solar time care usually care about the local solar time, while UT1 is a 'mean solar…
CDMA system time is already defined as free of leap seconds. --- 3GPP2 C.S0002-A section 1.3 "CDMA System Time": All base station digital transmissions are referenced to a common CDMA system-wide time scale that uses the Global Positioning System (GPS) time scale, which is traceable to, and synchronous with, Universal Coordinated Time (UTC). GPS and UTC differ by an integer number of seconds, specifically the number…
My CDMA phone dropped service for a few minutes after the leap second. It's absurd that we continue to keep subjecting ourselves to these disruptions and the considerable amount of work that goes into handling leap seconds for the systems that aren't disrupted by them. Leap seconds serve no useful purpose. Applications that care about solar time care usually care about the local solar time, while UT1 is a 'mean solar…
Earlier quoted context omitted.
CDMA system time is already defined as free of leap seconds. --- 3GPP2 C.S0002-A section 1.3 "CDMA System Time": All base station digital transmissions are referenced to a common CDMA system-wide time scale that uses the Global Positioning System (GPS) time scale, which is traceable to, and synchronous with, Universal Coordinated Time (UTC). GPS and UTC differ by an integer number of seconds, specifically the number…
But yet, parent poster's phone dropped, so that migration from UTC=GPS+N to UTC=GPS+N+1 would result in the same conniptions we all have to deal with an extra second in the day. Even if it is at the phone's presentation layer, that's several GB of software that might hold lurking N+1 bugs causing the data layer to drop.