I hope you're saying this in jest, but even then the meme that "2016 has been the worst!" has been pretty insufferable. It's usually used in the context of celebrity deaths, but think about the explosion of mass media that occurred between the 70's and today.
With more TV channels, radio stations, and the internet, the number of public figures we're exposed to on a regular basis is far greater than any generation before us. And like all of us those people die, and will keep dying, and the half-hearted and self-centered social media mourning will become even more commonplace.
I, for one, can accept celebrity deaths, but I'm not sure if I can accept the annoying cultural impact they seem to be having.
It's not just about the deaths, but also about the social and political events that have occurred. It can be argued that this has happened before at this frequency also and mass media is the culprit, but if the cultural impact is more awareness we should applaud it, not shy away. Annoying as they are, social media and memes offer a way to connect many to an idea and make things a bit more light-hearted as well.
My frustration is more with the reaction to celebrity deaths where people use the death as a means to focus attention on themselves, and how a lot of people seem to think that a magic cosmic switch will turn off on December 31 and they'll stop happening.
No argument here. But what makes 2017 so special that these same sorts of events (or even more drastic ones) won't continue? Placing any amount of hope solely on an arbitrary date by wishing for a sooner end to 2016 just seems asinine.
I'm not sure why people believe 2016 ending will somehow end the misery but I can understand why they hope it will. I think it's a bit tongue-in-cheek.
Nobody thinks the year boundary has real meaning with regards to this or that anything will change. We spread the meme as a way of experiencing the observations of 2016 together and finding comfort in making it a shared phenomenon rather than one to experience alone. Rest assured, we know that attaching meaning to 2016 is symbolic and that "2016" is not a property of the universe that brings any intrinsic context to our civilization.
I, unfortunately, still have a bit of a compulsion for social media, where this has been a growing trend since about June, but it has seeped into my workplace as well.
I always found this a fascinating way to deal with the problem of leap seconds. I've been tempted to switch my servers from UTC to TAI to avoid the leap seconds altogether but I've been coming to realize that the clock being out of drift is more likely to confuse my coworkers than "just" dealing with a non-local time offset. Maybe I'll do this myself before the end of the year - but who am I kidding, I don't have time to reconfigure my NTP server right now.
It is unclear for timezones behind UTC. If you are in UTC+1, the leap second happens at 1 am, so the countdown would be over: no fun here. If on the other hand you are in UTC-1, the leap second happens at 11 pm, so if the countdown clocks are not corrected for the leap second, friends can still be annoyed.
Have our timekeeping protocols really accounted for future events like that? It's my understanding that NTP really only synchronizes time periodically.
Your phone/computer should (according to the standard) know when the leap second is and apply it. NTP etc. transmit the information about leap seconds well in advance.
NTP includes flags for "leap second at the end of day", so devices that check NTP time at least once a day get the information. The systems internal list of leap seconds is possibly updated before that through normal system updates.
There's a bunch of ways the leap second can be reflected. :59 twice, :60, leap second smearing (adding small amounts of time leading up to midnight). How your particular system reacts depends on the use, how it's configured, etc.
That makes sense. I was being slightly facetious, and I think most devices would NTP re-sync after some interval. But it would be cool if my phone did in fact show 3:59:60 (I'm pacific time) and/or analog smartwatch paused on the 59 for two seconds.
A small point I missed that is covered in this article: leap seconds aren't added just because of the slowing of the Earth's rotation (as I've always explained it to others), but because atomic time is a few milliseconds per day faster than Earth time in general.
Not sure how I missed that in previous discussions of leap seconds, but now I can comfortably spend my leap second in 2016 basking in this knowledge.
Why couldn't they define the leap second more precisely then? I think there has to be an astronomic reason for the leap second. Either the Earth is slowing down or maybe the they want better alignment between the earth daily rotation and annual revolution.
The weight of one person varies around 1kg each day depending of several factors. One measurement of one pound less doesn't necessarily mean any weight loss. She could have even gained some (minor) weight.
Being off by a millisecond is already too much for practical use, if I recall correctly.
GPS needs something more precise anyway, it's not for these systems that we need to include whole-second corrections. And besides, GPS doesn't actually use leap seconds.
Personally, a leap hour seems about the right level of granularity, but I suppose an approximately once per century leap minute would be ok. But leap seconds are a waste of time.
If ignored since their introduction in 1972, official time would be out of sync with the Earth's rotation by 26 seconds. There's been a lot of running around and gnashing of teeth to correct 1.845668179868485e-7 error that isn't even an error most of the time. The 26 seconds of error fleshes out as 7.389 meters at the equator when using celestial navigation and for anything that accurate we use radio signals not a sextant.
The Earth's rotation and revolution are useful abstractions at a certain level of granularity. But the reason we have atomic clocks is because those abstractions break down when we need precise measurements of reality. Reality is real because the rotation and revolution of the Earth are not cosmological constants. Leap seconds are an expression of the superstition that humans control the arrow of time: as if one thing happening after another would cease to be the case without them.
An error of 7 meters would probably mean the FAA would refuse to certify GPS for aircraft use. Even now it's only usable in many circumstances with ground based corrections (eg WAAS or GBAS). A minute of error would probably make it unusable for enroute navigation.
Interesting. I didn't know that. I think half of the point remains (what sounds like a small error can be critical) but I guess GPS isn't a great example, then, as safety critical systems tend to be smarter by design anyway.
The safety critical systems don't reset their clocks because safety critical systems maintain independence in order to maintain safety. Safety critical systems are a place where the abstraction of a Terran Year as a cosmological constant breaks down.
GPS is indeed happily unaware of leap seconds, it started counting seconds on January 6th, 1980 (UTC) {1 week is 604800s, weeks count 0..1023, there already was one rollover}.
A few minutes ago, when the screenshot was taken, this was second #501074 in week #1928.
As a courtesy to users, GPS transmits the current number of leap-seconds inserted in UTC (currently: 17) and the fact that a leap-second will be inserted the next occasion (end of this year: "LEAP PENDING!"). That's of course very helpful when you are using GPS disciplined clocks for timekeeping.
The error would be in celestial navigation not GPS. The frame of reference for a satellite orbiting the earth is the same as the edge of the landing strip.
We use leap seconds, instead of minutes of hours exactly because mostly everybody can ignore them.
Unless you are doing something very interesting, that relies on some absolute standardized time (ie. not relative measurements) and requires great precision, you'll throw away clocks faster than they will accumulate errors. That's a feature, not a bug.
I exaggerated, latitude can be determined without a clock from celestial objects. Longitude requires both a synchronized clock and an equation of time (because noon GMT varies). [1] The equation of time is published. Rather than adjusting all the clocks in the world, the equations could be modified to account for additional variation.
I over estimated the effect of an absolute clock shift upon celestial navigation. The actual number is 0 meters because the absolute clock shift affects both the reference clock and the referencing clock equally when determining longitude.
Question for the experts. Say I'm writing a bunch of code for date/time stuff in JavaScript, using the built-in `Date` API. Is this something I need to worry about? I've read countless "falsehoods programmers believe about time" blog posts but they tend to not explain the why of it.
They also don't offer or explain any solutions. I've found the 'falsehoods' articles are good for generating discussion and not much else. They make the writer feel clever, without having to do anything.
I'm making to no claim to being an expert. Nevertheless, my question is "Does one second matter to your application? If so, how does Javascript's single threading, garbage collection, and default asynchronous programming idioms fit with the needs of a real or near real time system?"
JavaScript timestamps are POSIX timestamps times 1000, and POSIX timestamps have to be corrected for leap seconds at the OS level, not in the application.
The advantage of this is that 1483228800000 is definitely the start of 2017 (and in general, UTC days start on multiples of 86400 seconds, or 86400000 in JS). The disadvantage is that Date(1483228799999) could happen twice, and the first time it would be followed by Date(1483228799000).
In your application, you have to be able to cope with time going backwards for a moment. (But this is already true whenever your system contacts an NTP server.)
Good reminder to use Google's public ntp servers, which perform leap-second smearing[1]. This is the only sensical way to handle this without strange edge cases in every-day software.
Leap seconds have no business being tracked in the core logic of our programs.
Just like timezones and calendar changes, leap seconds are a display issue. While obviously very important in some circumstances there's no need to keep track of them through absolutely all of our code.
If the way you measure time takes leap seconds into account, you have no way of saying "exactly X Système international seconds from now". This is a big deal.
> If the way you measure time takes leap seconds into account, you have no way of saying "exactly X Système international seconds from now".
Note that this is the case for anyone using POSIX time, which inherently assumes that hours start on multiples of 3600, and has to be adjusted or smeared when a leap second happens.
But I've never seen a system that follows your recommendation, using TAI as the internal time and something like TAI-5:00:36 as the local time, except for GPS devices.
89 comments
[ 3.2 ms ] story [ 146 ms ] threadEverybody brace yourselves for that second, lest another cool person die! :P
With more TV channels, radio stations, and the internet, the number of public figures we're exposed to on a regular basis is far greater than any generation before us. And like all of us those people die, and will keep dying, and the half-hearted and self-centered social media mourning will become even more commonplace.
I, for one, can accept celebrity deaths, but I'm not sure if I can accept the annoying cultural impact they seem to be having.
Even before we approach Bowie it's been pretty dreadful.
https://www.youtube.com/watch?v=eFTLKWw542g
Although it covers 40 years:
https://en.m.wikipedia.org/wiki/We_Didn't_Start_the_Fire
This is the first time I've heard it mentioned. For finding it insufferable, you just spread the word.
Don't get me started on 1942.
https://www.flickr.com/photos/127045916@N06/31678955582/
Counting the leap second twice is more of a quick hack used in computers, but it's not how it actually works
Not sure how I missed that in previous discussions of leap seconds, but now I can comfortably spend my leap second in 2016 basking in this knowledge.
10,9,8,7,6,5,4,3,2,1,[Insert Shell Code]
/root/ #:
(Sorry, drunk)
In real terms, does it really count?
A few months back, a friend of mine was so happy when she got on a scale and found that she's lost one pound. One pound!
GPS needs something more precise anyway, it's not for these systems that we need to include whole-second corrections. And besides, GPS doesn't actually use leap seconds.
If ignored since their introduction in 1972, official time would be out of sync with the Earth's rotation by 26 seconds. There's been a lot of running around and gnashing of teeth to correct 1.845668179868485e-7 error that isn't even an error most of the time. The 26 seconds of error fleshes out as 7.389 meters at the equator when using celestial navigation and for anything that accurate we use radio signals not a sextant.
The Earth's rotation and revolution are useful abstractions at a certain level of granularity. But the reason we have atomic clocks is because those abstractions break down when we need precise measurements of reality. Reality is real because the rotation and revolution of the Earth are not cosmological constants. Leap seconds are an expression of the superstition that humans control the arrow of time: as if one thing happening after another would cease to be the case without them.
"Adding leap seconds is a waste of time" I see what you did there. And agree!
http://imgur.com/a/uq6D0
A few minutes ago, when the screenshot was taken, this was second #501074 in week #1928.
As a courtesy to users, GPS transmits the current number of leap-seconds inserted in UTC (currently: 17) and the fact that a leap-second will be inserted the next occasion (end of this year: "LEAP PENDING!"). That's of course very helpful when you are using GPS disciplined clocks for timekeeping.
Unless you are doing something very interesting, that relies on some absolute standardized time (ie. not relative measurements) and requires great precision, you'll throw away clocks faster than they will accumulate errors. That's a feature, not a bug.
The earth rotates about 12 km along the equator in 26 s.
Is the error of ~7 m for determining your position north-south wise? East-west it should be about 12 km then I think.
https://en.wikipedia.org/wiki/Equation_of_time
Yes. And it's not just real-time; even when just displaying dates and times, an off-by-one error at any granularity can bump it into the next year.
I guess what I'm wondering is how does the decision to add a leap second here or there find its way into system clocks, such that it knows whether:
...is 2016 or 2017?Depends on where one is. It takes 24 hours for the New Year to propagate. The maximum error during propagation is < 0.00115741%
Assuming that .getUTCFullYear() is accurate, the maximum error for a leap second is:
The duration of that error is one second. Curious about the nature of the application.The advantage of this is that 1483228800000 is definitely the start of 2017 (and in general, UTC days start on multiples of 86400 seconds, or 86400000 in JS). The disadvantage is that Date(1483228799999) could happen twice, and the first time it would be followed by Date(1483228799000).
In your application, you have to be able to cope with time going backwards for a moment. (But this is already true whenever your system contacts an NTP server.)
1. https://developers.google.com/time/
A good resource for red hat linux is https://access.redhat.com/articles/15145. And another resource is https://ics-cert.us-cert.gov/sites/default/files/documents/B...
Just like timezones and calendar changes, leap seconds are a display issue. While obviously very important in some circumstances there's no need to keep track of them through absolutely all of our code.
If the way you measure time takes leap seconds into account, you have no way of saying "exactly X Système international seconds from now". This is a big deal.
Note that this is the case for anyone using POSIX time, which inherently assumes that hours start on multiples of 3600, and has to be adjusted or smeared when a leap second happens.
But I've never seen a system that follows your recommendation, using TAI as the internal time and something like TAI-5:00:36 as the local time, except for GPS devices.