Extra Leap Second To Be Added To Clocks On June 30
hcs_$reboot writes: On June 30 this year, the day will last a tad longer — one second longer, to be precise — as a leap second is to be added to clocks worldwide. The time UTC will go from 23:59:59 to 23:59:60 in order to cope with Earth's rotation slowing down a bit. So, what do you intend to do during that extra second added to that day? Well, you may want to fix your systems. The last time a leap second was added, in 2012, a number of websites, Java and even Linux experienced some troubles. Leap seconds can be disruptive to precision systems used for navigation and communication. Is there a better way of dealing with the need for leap seconds?
"Is there a better way of dealing with the need for leap seconds?"
Sure, use/write software which correctly handles time. Leap seconds with their current, well defined behavior, have been around for over 40 years.
If you have software which assumes a minute is always 60 seconds, an hour is always 60, 60 second minutes, etc., you're doing it wrong.
"National Security is the chief cause of national insecurity." - Celine's First Law
Well, i hope DST would be abandoned sooner.
If it's not network connected (ntp or gps), or connected to a properly calibrated atomic clock, it's going to be off by more than a second when the next leap second rolls around, anyway.
If you don't need time accurately sync'd to UTC, you can ignore leap seconds, so what's the problem? And if you do need time sync'd to UTC, you will need some regular external input which can include upcoming leap second info, so what's the problem?
"National Security is the chief cause of national insecurity." - Celine's First Law
I hope they don't chose option A. It's a hack. We already have a timescale that doesn't add leap seconds: TAI. Changing the definition of UTC is just a hack to fix broken systems. But there are so many other problems with the way systems handle time that it's kind of a moot point.
Properly written software that requires continuance SI-seconds units will use TAI or if they don't need a global reference a local monotonic clock.
Even TAI is something of a lie. Relativity tells us that time is relative, so any global reference clock on earth necessarily has limited precision.
My favorite time scale is POSIX. They define a day as precisely 86400 "seconds". Obviously a POSIX second is not the same as an SI second. But it makes it trivial to compute past and future dates using a 4-line algorithm. And for _civilian_ usages, it's all you'll ever need. If you need high precision or scientific accuracy, you shouldn't be using UTC anyhow.
The root of the problem is that people don't think about what kind of clock reference they really need. And when they convert, they don't think about the lossiness of conversion between different time scales and units. (Like with floating point arithmetic there are rules you can follow.) Hacking UTC won't make the idiots any smarter, and it's a fool's errand to think that the whole world wants or needs a single global time reference.
Civilian time should be synchronized to the sidereal day. Business records don't need sub-second precision; 99% of the time we think in larger units like minutes, hours, and days. And all they matters is the transition between one minute, one hour, or one day to the next, regardless of the duration of an SI-second. Leap seconds and leap years are a decent compromise.
People need to _think_ about the function of time in their applications, and stop pretending like it's a simple problem or that it can solved for you by tweaking international standards. Alternatively, just adopt the POSIX definition of the second and the day and be done with it. A POSIX day is 86400 "seconds", and by implication a POSIX "second" is not the same as an SI second and doesn't (cannot!) have a fixed duration. But that will work for the vast majority of civilian business applications. POSIX also defines a monotonic clock, which should be the local reference for an SI-second. And for the very few applications (mostly scientific) that rely on a global reference clock, just use TAI.
Problem solved. And I didn't even need to redefine the concept of time to something completely alien to normal humans.