6 ms·
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 c
by nullc 10y ago
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 time' that doesn't really have much physical meaning (it's not a quantity that can be observed anywhere, but a model parameter).
It would take on the order of 4000 years for time to slip even one hour. If we found that we cared about this thousands of years from now: we could simply adopt timezones one hour over after 2000 years, existing systems already handle devices in a mix of timezones.
[And a fun aside: it appears likely that in less than 4000 years we would need more than two leapseconds per year, sooner if warming melts the icecaps. So even the things that correctly handle leapseconds now will eventually fail. Having to deal with the changing rotation speed of the earth eventually can't be avoided but we can avoid suffering over and over again now.]
There are so many hard problems that can't just easily be solved that we should be spending our efforts on. Leapseconds are a folly purely made by man which we can choose to stop at any time. Discontinuing leapseconds is completely backwards compatible with virtually every existing system. The very few specialized systems (astronomy) that actually want mean solar time should already be using UT1 directly to avoid the 0.9 second error between UTC and UT1. For all else that is required is that we choose to stop issuing them (a decision of the ITU), or that we stop listening to them (a decision of various technology industries to move from using UTC to TAI+offset).
The recent leap smear moves are an example of the latter course but a half-hearted one that adds a lot of complexity and additional failure modes.
(In fact for the astronomy applications that leap seconds theoretically help they _still_ add additional complication because it is harder to apply corrections from UTC to an astronomical time base due to UTC having discontinuities in it.)
- hartator 10y agoOr maybe we just need to code system that handles leap seconds correctly.
- whyileft 10y agoOr maybe we should start holding project managers accountable for these issues instead of simply basing their performance on deadlines.
- admax88q 10y agoClassic Hacker News, it's always the PM or the management at fault, engineers are faultless.
- na85 10y agoI'd have time to develop a new toy programming language as a service alongside 3 new JavaScript frameworks in 2017 if it weren't for the evil PMs.
- whyileft 10y ago> if you can’t measure it, you can’t manage it.
- craigvn 10y ago;-) 98% of developers would be clueless to leap second issues. Hell, 50% struggle with leap years.
- lend000 10y agoTwo valid points. A third: convince everyone to adopt epoch time for data transfer (seconds since epoch), and let applications that require formatted time do the transformation where it will be used (not earlier). It doesn't make a lot of sense that a timestamp represented as HOUR/MIN/SEC:DAY/YEAR should be passed around on the network of a production system. Leave it to the recipient to convert. I guess this is a subset of your point.
- swiley 10y agoI wrote a WebDAV client the other year and dates where one of the hardest parts to implement because they expected them in calendar format! It seemed so odd to me that they would do that.
- deleted 10y ago[deleted]
- cm2187 10y agoBut is it a bug or network saturation under people wishing each others a happy new year? (And Perhaps more so with a selfie than a text msg as prev yrs)
- deleted 10y ago[deleted]
- toast0 10y agoGiven that it's cdma, moat likely the user was in the US or thereabouts, so the leap second was several hours before local new year.
- nullc 10y agoHappy new year at midnight UTC ... in the Pacific timezone? Doubtful. :) I've observed a similar outage at the last leapsecond (and in that case, dropped me off a call-- which is why I even checked this time.)
- joecool1029 10y agoAtt got hit too. Dupe sms everywhere. Neville, the T-Mobile CTO was kind enough to answer me asking on their prep for it. https://mobile.twitter.com/vvtgd/status/814654159614050304 https://mobile.twitter.com/vvtgd/status/814654159614050304
- yuubi 10y agoCDMA 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 of leap second corrections added to UTC since January 6, 1980. The start of CDMA System Time is January 6, 1980 00:00:00 UTC, which coincides with the start of GPS time. System Time keeps track of leap second corrections to UTC but does not use these corrections for physical adjustments to the System Time clocks. --- I'm pretty sure the only use of leap seconds in CDMA is for converting system time to customary local time, along with the daylight-time indicator and time-zone offset also contained in the sync channel message. Edit: C.S0005-E section 2.6.1.3 says the mobile station shall store most of the fields of the sync channel message; it may store leap second count, local time offset, and daylight time indicator. This suggests that these fields aren't really that important for talking CDMA.
- imglorp 10y agoBut 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.
- deleted 10y ago[deleted]
- kevin_nisbet 10y agoAgreed, while the CDMA specification requires tight time syncing, like everything else the UNIX OSs used to run the equipment can receive the leap indicator. Any problem within the OS, or the software reading date/time from the OS can cause instability. Also, without knowing more about what exactly went wrong with your phone, it's possible other infrastructure within the network was unstable, signalling equipment, etc. I can't remember exactly, but I think some of the CDMA equipment at my previous company had a leap second problem previously. And the equipment is no longer being maintained or patched really.
- bluejekyll 10y agoWhile we're at it, can we get rid of daylight savings time too?
- toomanybeersies 10y agoAs a programmer, I hate daylight savings, but asa human being, I love daylight savings. It's just so nice to get that extra bit of sunlight in the evening.
- JshWright 10y agoAs a human being, I hate daylight saving time... It's very disruptive to sleep schedules (particularly for children, but adults as well). Traffic accidents spike in the days after the DST switch (likely due in part to the aforementioned sleep disruptions). Summer days are plenty long already...
- Philip_with1L 10y agoYes, exactly my thoughts. While it's great that automated systems and networks can account for this man-made invention of time change, it is very stressful on humans and also unnecessary. A dissolving and averaging out to a new standard would help everyone out in the long run..
- fapjacks 10y agoOr we could just keep time on DST and stop switching. No reason to give up those nice, long summer evenings.
- deleted 10y ago[deleted]
- rndgermandude 10y agoJust do a leap minute every 60 theoretical leap seconds and reduce the number of times these problems occur by 60 (and they always do because fallible humans programming machines).