The idea that I don't know how many UTC seconds will pass between now and May 15, 2022 0:00:00 is absurd. The fact that a clock sometimes reads 23:59:60 is also absurd, as is the "possibility" of a 23:59:59 being a forbidden time on a certain date if we ever add a leap second of the opposite sign.
That being said, why your approach doesn't work is that there are several hard astronomical or cultural definitions that you'd throw off by playing with time.
A day is defined as the rotation of the earth around its axis.
A week is a hard cultural and religious boundary for just about everything in life.
A month is roughly the rotation of the moon around the earth (although that definition is arguably the weakest and ready to go)
A year is defined as the rotation of the earth around the sun.
Changing any of these will make the summer drift into the winter, or the night into the day, or whatever.
Time just isn't simple, and although most of these intervals _almost_ fit within each other, reality is that they don't and we'll always have artifacts.
If you enjoy philosophy on these kinds of imperfections as much as I do, I can heavily recommend this article about musical tuning: https://blogs.scientificamerican.com/roots-of-unity/the-sadd...
The US has put forth a proposal to abolish leap seconds. It is now supported by China, Australia, Japan, and South Korea. The ITU keeps punting on actually voting on it - it's now scheduled for 2023.
A day already drifts... every single day in fact. Why is 0.9 sec the magic threshold for maximum drift? Why can't it be 1 minute of drift, or 1 hour of drift? We are putting out problematic corrections for something a minor drift on the scale of years that should be happening on the scale of centuries or millennia in my opinion.
The Earth's rotation is slowing down (by about 2 ms per day per century), so the difference between TAI and UT1 is increasing quadratically, not linearly.
Imagine what would happen when the International Date Line ends up in the middle of the US.
If the drift is about 0.5 second per year, about a minute of drift will have to be compensated on a century border.
So, if leapseconds are actually painful for you, then maybe we need to contemplate making this kind of adjustment on a finer timescale, like milliseconds.
OTOH, if you think leapseconds are painful now, just you wait until you postpone this pain and do it even less frequently.
For example, deleting your entire codebase and firing all your developers is painful, but even the most continuous deliverer wouldn't advise you to do that more often.
Getting past pedantry, the advice is obviously about foreseeable, repeating parts of normal business, and it applies to more than devops.
A long time ago (tail end of the "desktop publishing revolution"), I was a production assistant, and then manager at a magazine. We published six times a year. Towards the end of my first year there, I realized we had the same problems, right down to our Advertising Director's emotional meltdown, every. single. issue.
After getting to know folks working at other magazines and people at our press, I noticed that the monthlies seemed to run smoother with less drama, and the weeklies were even better at it. Eventually I realized it was because they had to be. If there was some minimum amount of human drama that had to happen, it was forced into exhibitions that didn't disrupt the (tight) schedules. If last-minute changes from flakey advertisers came in, they didn't cause a firedrill, they just didn't run, because that issue is already on the press and we're talking about the issue after next now. And so on.
The general principle is actually very straightforward, and applicable all over the place, including your personal life. If you have high-friction processes, devoting time and attention to them is the way you make them lower-friction processes. And while it may be possible to do that without doing things over and over until you get there, it probably is not possible for you to get there without repetition, else you'd not have the problem in the first place.
That is what a lot of organizations do, "smearing" the leap second since they know their systems can't handle the discontinuity. I think this shows that software has failed in general at handling leap seconds correctly. As another said, I think leap seconds are unnecessary complexity with the frequency at which they happen.
That only works assuming you need to do it at all.
If leap seconds are useless (to the majority of users) or insufficient, not doing them is preferable to doing them constantly.
The best solution is probably just to use a nice number of seconds per day and accept the fact that in 100ish years summer will start in March, not December. It's not like we need to build our entire society around planting and harvest any more.
Not to mention with climate change, we're probably going to have to deal with many other changes in season etc. anyway.
All of us deal with the fact that the day gets shorter and longer every year anyway (and daylight savings didn't seem to be a terribly good solution).
I think having the seasons slowly drift is a non-issue, provided it's just slow enough to not be noticeable from year to year.
Of course, once you start dealing with astronomical distances and speeds, the whole concept of a single universal measure of time kind of goes out the window anyway so it's probably going to get worse, not better. :P
(FWIW my definition of 'best' here is something along the lines of 'simple, no special rules or tinkering, gets translated to a human-readable local time on demand'. Which is pretty much how Unix epoch works, come to think of it.)
This has nothing to do with leap seconds. Leap seconds are the worst mechanism in keeping time, there's not a single advantage to having leap seconds.
> A day is defined as the rotation of the earth around its axis.
And we can now measure time with precision high enough that tying to Earth's rotation is not acceptable. We can still use timezones to fix the shift.
> Changing any of these will make the summer drift into the winter, or the night into the day, or whatever.
Yeah, and it will take a millennium for Earth rotation to shift enough for people to notice it. On the other hand, you'd have no problem with summer/winter time I presume?
No, I don't, as they are just views on a monotonically increasing time scale named UTC that keeps up with Earth's rotation, so that every single thing from climate diagrams to everything else humanity is syncing on keeps working and being comparable.
> We can still use timezones to fix the shift.
Or, we could not do that. Everyone is free to use TAI inside their own projects as they see fit if they have the needs for strictly monotonically increasing time. I would argue that leap second smearing has way less artifacts in practice than bolting time zones onto a shifting UTC time.
Leap days, sure.
Leap seconds - as the article points out, there have only been 27 so far since 1970. Less than a minute per century isn't much drift, and could be corrected in a bigger block later.
When you get into the world of programming for most people, businesses especially, a day is defined as 24 hours. We like to think that our days and months and years are tied to vast astronomical forces, for romantic reasons, but when it comes down to it, everything comes back to the second, and the second is defined to be a single unvarying length of time.
In TAI: A day is 24 hours (86400 seconds always), and a second is a SI second.
In UTC: A day is a rotation of the earth, and a second is a SI second. (And since these are incompatible, we have to introduce leap seconds).
In UT1: A day is a rotation of the earth, and a second is 1/86400 of a rotation of the earth.
Julia, interestingly, uses the UT1 notion, thus avoiding leap seconds, IIRC.
If you want to nitpick, you're going to need to start with Cesium-133 oscillation periods as averaged from over nine billion samples.
This matters when computers are bouncing records about time around satellites and across the global.
Edit: I have no idea what I’m talking about so please do not hesitate to correct me on the particulars!
A bit like complaining that UTC is wrong because it doesn't match your local Solar time.
Best to define a second as a certain distance light travels in a vacuum and use that to build minutes, hours, etc. Then, have a fixed geo reference point (like, say, geo 0:0) that holds an atomic clock as a main reference.
We are only really talking about local coordinate changes in the time dimension, really, so might as well simplify.
I would prefer to call it quasiperiodic.
The speed of the Earth's rotation is slowing over time. Therefore leap seconds are becoming more and more common. In a century, we should be averaging something like 1 a year. In 500 years, we should be averaging one every few months. And so on.
It took over a thousand years for the Julian calendar to fall apart. Our current timekeeping system will also fall apart eventually, and I would be surprised if it lasted as long.
Regardless, we've had maybe half a minute of drift since the 1970's. If the drift is 1 minute in the 2000's, 1 second per year in the 2100's, 2 seconds per year in the 2200's, 3 seconds per year in the 2300's, etc., then by 2500, the cumulative drift would add up to...60 + 100 + 200 + 300 + 400 + 500 or 1560 seconds of total cumulative drift by 2600. That's less than half an hour. If we didn't bother accounting for leap seconds, UTC midnight would be only half an hour off from astronomical midnight in 600 years, which is roughly the same error inherent in most time zones.
It will take on the order of a thousand years for the discrepancy to add up to an hour. In 5000 years, it will be around a day. The fact that it is currently growing about a minute per century is true, but not a good predictor of what will happen.
That said, I prefer if we just lose the astronomical basis for time keeping, and let our distant descendants figure out that they should use time zones, and not modify UTC. Hopefully by the time it becomes obvious that clocks are drifting too fast for time zones to change all of the time, we're a multi-planetary species and paying attention to what is happening on the Earth seems quaint.
B. If you want to be super strict about it, as I imagine you do, that scheme would hit problems with relativistic effects. Local time is the only real time.
>A year is defined as the rotation of the earth around the sun.
Sounds like we need a generic geo-solar measurement.
Right now those two things are intertwined, and that's bad. Not everyone eats lunch around noon or go to bed at 23:00 anyway, so the cultural part is very fuzzy.
I should be able to describe time in an almost metric way. A unit that is the same no matter where I am in the world and doesn't change based on how fast a rock moves around a fireball. "Hey person in Japan, let's have a video meeting at 1,234,99" where that number means the same thing to the as it does to me. Its going to be dark for one of us and bright for another.
Then we can have a different unit, let's call it "day offset". That is the offset from the first number that dictates when a particular area considers to be "the day", when the average people wakes up, have lunch, have dinner, go to bed.
"Let's meet at 1,234,99. I know you're in Japan and your offset is +9,23 while here it's "-5,78" so it's a bit inconvenient, but hopefully you can make it!"
Yes, I realize I'm roughly describing how time and timezone works, with an important difference: with the current system, people live around the adjusted number. The number after the timezone is applied. After the leap seconds and all that crap is applied. Some people argue about daylight saving or no. Computers have to deal with all of it. Let's make the non-adjusted number what people use day to day, and the "offset" is a static number picked by the locals, that include stuff like daylight saving, leap seconds, and various other cultural adjustment. Its only purpose is to communicate the cultural or location difference between 2 people.
Obviously that will never happen, but Ill keep dreaming.
It's perfectly sensible though? 0:00:00 is a designation of an event. Namely, the event of midnight during a particular rotation of our planet. Every calendar day is one rotation, so May 15, 2022 is also an event -- it's that many rotations of Earth after today. But a second is a duration and it's independent of Earth's rotation. An asteroid could hit the earth and make the rotation shorter or longer (or just shatter the planet...) in the meantime. You obviously can't know how many seconds will pass until that particular midnight. It's inconvenient, but it makes perfect sense when you can't predict the future.
The different time definitions exist to support different use cases. UTC isn't flawed, in fact the adjustments that keep it aligned to solar time are very helpful for its defined use cases.
It's just that time is complicated. If you think you will be doing time math where duration is paramount consider using TAI.
PS: for all those who think 'time' is complicated in fascinating ways, you should fall down the geodesy hole some time. Saying 'where' on earth something is located is .. not simple.
The problem is really the cultural and societal layers on top of it. That's not Time's fault, its Our fault. A "Day" has to be 1 rotation of the earth around its axis, a "Year" has to be 1 rotation of the earth around the sun, etc.
Every unit of time at the Second and below is Simple. Every layer above it is Complex, including the counter of seconds from any date in the past, because Humans are Complex, not because Time is Complex. If we stopped caring that it always has to be cold in Winter (in the US) or that 7am is always morning (well, sunrise changes w.r.t both time and location), or that days are always (usually) 86400 seconds long, our interactions with time would be much simpler.
And, really, given that EVERY SINGLE UNIT above the second has not just some but many special case rules that are instantly confusing, maybe we should stop caring so much.
If the second uses some other definition, you still need some centralized authority to define its length, for the same reason that it’s measurement will drift depending on your reference frame.
This is an excellent insight. Thanks!
I remember an ancient mathmatician described how all of existence must be a single geometric point, I think it was Euclid, but I can't find it. This all reminds me of that.
The user above listed several explicit cases that seem needlessly complicated. Can you give examples where the adjustments to UTC are so helpful for its defined use case? Or elaborate what that case is?
I'm not trying to be obstinate - it's just that without examples your response boils down to "No it's not" without further support. I'm open to being convinced...convince me.
 I'll save the rant on DST.
The sun isn't even highest in the sky at noon! Firstly because of timezones (your noon is based on highest-sun in the middle of your timezone, not your current longitude), and secondly because of this whole epicyclic botheration:
In the higher latitudes, it requires even less acclimation once you've got an idea of your orientation, and maybe what the stars look like. To the point that, at the poles, a clear sky is a direct-reading 24-hour clock.
The first thing is for time zones, inclusive of DST/Summer Time/etc. The second thing is for calendrical reform, which we've basically stopped doing now that the Gregorian calendar is as widespread as it's going to be. Leap seconds are for this:
> Currently the Earth runs slow at roughly 2 milliseconds per day. After 500 days, the difference between the Earth rotation time and the atomic time would be 1 second. Instead of allowing this to happen, a leap second is inserted to bring the two times closer together.
The "error" induced by the Earth slowing amounts to 12 minutes over the course of one thousand years.
Without leap seconds, UTC will slowly drift out of sync with the Earth's rotation.
What use case in the year 2019 is made easier by UTC getting leap seconds instead of treating it as a monotonically increasing scale (TAI)? I'm genuinely interested. The only suggestion I have ever heard is use of a sextant -- what an anachronism in the modern world...
I'll add in; astronomers like to be able to find objects in the sky using calculations based on time. UTC (actually TT, which underlies UTC) is good for that.
Spend a little time on the various wiki pages for time standards, and think about why those things exist.
Your noon example works for a single longitude in a time zone and the time between subsequent noons on two different days will only be exactly 24 hours 4 times a year. It seems unnecessarily complex to push annual leap second updates to preserve something like as obscure as these 4 events for the 24 time zones exactly on the line of longitude to the accuracy of a second.
See the Wikipedia on abolishing leap seconds,
"that the drift of about one minute every 60–90 years could be compared to the 16-minute annual variation between true solar time and mean solar time, the one hour offset by use of daylight time, and the several-hours offset in certain geographically extra-large time zones"
I believe you are actually converting to Terrestrial Time.
If there is a correction of TAI+32.184 seconds in your calculation, that would indicate TT.
I could argue the TAI to TT is the second step. But let's put the pedantry aside: Is your best answer of something made easier in the modern world by leap seconds ensuring that solar noon happens at exactly 12:00:00 four times a year on an exact line of longitude for the time zone? And 4 times a year would require a time zone that does not honor daylight time, otherwise it is twice.
I'm not some crackpot here talking about the absurdity of leap seconds. US, China, Australia, Japan, S. Korea are on board for discussions about abolishing to happen in 2023.
No question about that; leap seconds have been controversial since they were invented. The question is whether "the juice is worth the squeeze" which is of course an opinion rather than a fact.
The nice thing about time standards of course is that there are so many to choose from. All of them have flaws when you try to use them the way we do in civil time applications.
In other words, if you have a simple to understand thing, then it might become hard to understand if it needs to be fed into something that is itself hard to understand. (Or even if the way in which you feed it into the other thing is hard to understand).
Additionally, if you have something which is easy to understand that is fed into multiple incompatible things (either the things are easy to understand or hard to understand), then the whole system becomes harder to understand.
Finally, if the starting point that is fed into all other things is not actually easy to understand but in fact hard to understand ... things can get pretty bad.
Even if time was easy to understand by itself, then I still think it would be pretty hard to deal with because it is used for multiple incompatible domains (astronomical vs how long a day is on earth for example).
With regards to time specifically, I recall many years ago talking with an economics professor I had that was from Zimbabwe and he mentioned the frustration that western industrial nations had when attempting to establish business in Africa. Industrial nations long ago became dependent upon a higher resolution and accuracy of time and so when they say "2PM" they expect accuracy within a minute or two. But the African work force would often show up at 3PM and when confronted by this "lateness" they would reply "3 is the friend of 2." An agrarian or pre-industrial society has no real need for accuracy to the minute, but instead can operate quite well with human observation of the position of the sun. This impedance mismatch caused no end of frustration on both sides, since neither could really fully understand the other's conception of timeliness.
Some people think that a day is one revolution of Earth's axis, and not exactly 86400 seconds. Leap seconds help to keep that reality.
The fact that axial rotation is less predictable than orbital paths is a quirk of nature.
One day is more than one revolution of the planet. The sidereal day is exactly one rotation of the planet, but that's about four minutes shorter than a civil day.
The reason is that the planet also moves around the sun, so in order to get the sun to the same position in the sky for noon the planet needs to turn a little bit more than 360 degrees, about 360/365 extra.
Also, it should be noted that basically nobody actually understands a "year" to mean an orbit of Earth around the Sun relative to the Local Standard of Rest, which is called a sidereal year (ca. 365.256 days). Instead, to most people, a year means a cycle of seasons which recreates the same angle between the Earth-Sun axis and the Earth's axial tilt, which generates seasonal temperatures and is called a tropical year. Because the axial tilt is variable, the tropical year also varies and eventually drifts away from the sidereal year. The tropical year and sidereal year differ by about 20 minutes, so today's year starts about a month "away" from the year Julius Caesar enacted the first true solar calendar.
The difficulty in this case is that spinning rocks in space can float around however they please.
That would keep the time and date adjustment code together in one place.
Here's my version of it:
Some people think one year is one orbit around the sun, and not exactly 365 days. Leap years help to keep that reality.
Some people think that a day is one revolution of Earth's axis, and not exactly 1440 minutes. Leap minutes help to keep that reality.
And now we are at less than one change every century!
On a long enough horizon, I take it as a foregone conclusion that simple metric measurements will become standard.
Even if you got rid of leap seconds, you still wouldn't know for sure how many seconds there are between now and some date and time in 2022 because you don't know what the local timezone will do. It's not clear why this is a useful calculation? For scheduling events in the future, you need to store the timezone (or location) and local time anyway.
Unix time is a useful approximation for comparing and converting between local times.
Not at all.
To quote Feynman: "Nature cannot be fooled".
The earth will rotatate in a (slightly) chaotic fashion. Midnight has a definition which is based on astronomy.
Thus, you need to adjust the length of a second (which is not desirable) or the number of seconds in a day.
A notion of an instant in time that advances linearly without any ambiguities, which would be TAI, and a notion of the precise orientation of Earth, which would be UTC.
To record events, you will use TAI, to point your telescope to a celestial object, you will use UTC.
You still need something that keeps track of the Earth's rotation, but presumably the ITU will still keep track of the difference between UT1 and UTC. I'm an (ex-) astrophysicist, but I'm not convinced that astronomy would actually be particularly impacted if leap seconds would stop being applied to UTC. You already need to keep a leap second table, it would just shift where you apply it.
Why don't you use TAI then for this purpose?
I think the notion of time in relation to the earth's movements (for timekeeping on earth) is fair.
You hear a lot of people remarking that Let's Encrypt has made things better by requiring certs to be reconfigured more often rather than less. I know they're not exactly the same as time in general, but as a general idea, knowing that you need to do some fiddling often and automating it, might be better than growing complacent because nothing needs to be done for 50 years.
Might be setting things up for a lot of work when that next change comes due.
The event was rather boring, because a huge effort went into making sure that critical infrastructure was "Y2K Ready".
So my point was that pushing the problem in front of us until it becomes too large to ignore, is not a good strategy when we're talking (it) infrastructure. Handling leap seconds every now and then are the lesser evil.
Then you convert from UTC to TAI.
And then you convert from TAI to the arrival time at the solar barycenter, removing the geometric light travel time to Earth (or more precisely the observatory) as well as the gravitational effects of Sun, Jupiter and Earth.
Instead of building it into all into the protocol and time libraries, it's so far into the future that "We don't have to worry about that". We've had that issue before with Y2K.
> Such jumps have occurred in the past (Julian to Gregorian)
In a very different time. Today it would not be as easy - in fact since time and date are ubiquitous, it's not a simple task at all.
> The idea that I don't know how many UTC seconds will pass between now and May 15, 2022 0:00:00 is absurd.
If it matters for your use case, the don't use UTC time?
I have worked on code that needed to do astronomical calculations to do things like:
position of sun, moon, Mars, Earth, and spacecraft
ECI <-> ECEF
All of these depend on a conversion from UTC to TAI. It's covered in books like Astronomical Algorithms in the intro:
It does seem logical use TAI for civil time. People interested in calculating the Earth's rotation to high precision could consult a regularly-updated publication somewhere.
Eventually the Earth's rotation will drift out-of-sync with the atomic clock timebase, but that won't be important until we accumulate several minutes/hours of error from TAI which could be centuries from now.
There is no device available that allow you to derive a clock from the relative motion of the sun about the Earth’s axis, such that the changing definition of days and seconds relative to realizable clocks can be tracked.
Furthermore it’s kind of nice to have a stable and standard definition of seconds and days. For instance, under the “ut1 system” you don’t know how long a present second is until the present day’s final observations are made.
They are a quantity of seconds (ignoring leap seconds & relativity) since a specific instant. That instant in time happens to conveniently line up with 1970-01-01T00:00 when described in UTC to make things easy for us. But it is equivalently defined as 1969-12-31T16:00-08:00 when described in another time zone. The elapsed quantity of seconds since that instant does not vary depending on how you describe the instant itself.
If offset or zoned. Sadly the average date string has no more inherent timezone information than a unix timestamp.
Alice and Bob both live in England and have planned a conference call at 15:00 on 4-jan.
Now Alice happens to travel, and she is in American on 4-jan. What should here calendar do?
Moreover, Alice also has a recurring event "Workout" every friday at 9:00, what should that shift to? Finally, it turns out Bob is also in America, what time should the conference call be at now?
Finally, for some reason England or America decides to change the DST changeover will now happen on 3-jan.
There is no universal semantics of time that will deal with every case. Certainly 'store UTC and convert to the users's time-zone' is not universal, nor is 'store every timestamp with a time-zone'. The way people perceive of 'do this thing at this time' is very hard to capture. Moreover I'd wager no users would actually fill out time with sufficient detail to deal with this. "What do you mean UTC, time-zone, or local-time" I just wanna work out at 9:00 every day, and meet with Alice at 15:00 in a few days. I thought computers were meant to make things easy".
You're describing UI/UX challenges with calendaring and appointments. Very real issues, but separate from Unix timestamps.
However, I saw a good tip once that you should only store timestamps of past events and events that happen at a fixed instant regardless of calendars and wall clocks as Unix timestamps. Timestamps for things like future calendar appointments (that may be affected by future changes in regions' timezone definitions) should be stored as a date and wall clock time and regional timezone, and only converted to a Unix timestamp when it happens. This makes it possible to see the timezone the user intended, let it be changed, and works well even if timezones themselves change before the event happens.
I think this works more often than not, but it's hardly foolproof or without repercussions. Say, you can imagine Google Calendar having a list of holidays for the US. Say it's New Year's day. You're saying you'd replicate that into 6 epoch timestamps (one per time zone in the US) per year in the past, instead of just storing it as "January 1, 00:00:00, recurring every year"?
That's less of a "falsehood", more of a complete misunderstanding of what Unix time is.
Unix times show up in a lot of APIs and aren't always explicitly called "Unix times". People just see that at some point there's an integer value representing a timestamp, and the time string displayed to the user is some number of hours off, so they think they need to change that integer.
So for example if you're in EST(-5) and need to Target CST(+8) you can't give the Unix time for the other timezone because that value is relative to yours talking about another timezone.
Got my upvote. I can't stand the "falsehoods programmers believe" articles that make a point out of not backing up any of their claims.
I've run across so many "how to do" and it's the same example code and you can see where it has skewed over time... and evolved into something that the author really doesn't understand.
Same goes with some of the fundamentals and gee wiz "falsehoods" and such articles.
I appreciate the folks taking the time to write it but if they're not going to tell me why:
1.) I don't know if they even know / gave me the right idea.
2.) If I can't grok why then I'm not going to really understand it...
Timekeeping is strange. Makes me want to store everything in TAI and then convert it for display.
Should I be flagging mandatory name fields as an I18N concern? How many people are affected? In which regions does this warrant UI hints or changes? Will they have names by the time COPPA stops applying?
I've casually Googled this and found nothing, so whatever point the author hoped to make was lost.
The Falsehoods listicles that were actually obvious were Falsehoods Most Programmers Don't Actually Believe.
The reason that this is not a problem is that most hardware clocks are pretty awful to begin with and need frequent automated corrections (through ntp). This does in fact cause that integer to increment/decrement locally when that happens and far more often than once every few years. This too is mostly a non issue. For practical purposes, time moves forward and when you access time using one of the many high level APIs you get a fresh interpretation of the system clock's integer. A much bigger problem would be the Y2038 problem when that integer overflows. I believe work is underway in the Linux kernel to address that.
From one of the previous lists:
> DST is always an advancement by 1 hour
I'd point to this one as not "obvious": it is false. Some extreme northern/southern locations (where the seasonal day lengths get really long/short, since you're so close to the pole) adjust by 2 hours. (E.g., the aptly named Antarctica/Troll.)
> Months have either 28, 29, 30, or 31 days.
> The day of the month always advances contiguously from N to either N+1 or 1, with no discontinuities.
I usually presume that I'm either a. working in the proleptic Gregorian calendar, b. I am working within a range of time (e.g., company start to foreseeable future) in which the Gregorian calendar is a safe assumption or c. I am working in a situation where I know I'm not working with the Gregorian calendar (e.g., the app/job has specific requirements around, say, a lunar calendar) and I'll know I'm in one of those exceptional case when they apply / the falsehood won't be believed to be false.
Within that assumption, that "falsehood" isn't false. It's true: there is no month within the Gregorian calendar that does not have 28, 29, 30, or 31 days.
The trouble is the transition onto the calendar. Some languages — in particular, some parts of Java do this — choose a date at which the calendar was adopted and actually expose that in their routines. (But note, however, that the Gregorian calendar was not adopted overnight; it started in 1582 and continued until 1923!)
For example, when Great Britain adopted it:
> Through enactment of the Calendar (New Style) Act 1750, Great Britain and its colonies (including parts of what is now the United States) adopted the Gregorian calendar in 1752, by which time it was necessary to correct by 11 days. Wednesday, 2 September 1752, was followed by Thursday, 14 September 1752.
Again using Java as an example, I believe it chooses the Spanish transition (1582), and since there's a jump there, too, it jumps 11 days, resulting in a very short October, making the two falsehoods listed above actually falsehoods.
But just work in the proleptic calendar. IMO, what calendar you're using is effectively part of the datetime type. Having a datetime type that uses multiple calendaring systems is like having a text/string type that also lets you put random bytes in the middle of the string.
Of course, the next falsehood was,
> There is only one calendar system in use at one time.
…which is our stated assumption of "within the Gregorian calendar". So, by definition, this is true!
There were a few others, e.g.,
> Non leap years will never contain a leap day.
That are just more fallout.
Assumptions need to be stated, and explanations would be more enlightening to the surprised reader.
Unfortunately, Unix time did not consider the effects of leap second, which broke the very foundation of Unix time and nullified all the benefits it had. A UTC change (leap second) will force you to update the system clock.
There is a way out: we should stop keeping time in UTC, instead, we do the timekeeping in TAI. And we provide a system-wide facility called "utcinfo" database to handle TAI-UTC conversation. Just like tzinfo, but much easier, it only needs to store all the leap-second events. All problems solved! I'm aware that the leap second still causes some issues: the kernel still has to be notified for the upcoming leap second for its UTC APIs, but still better.
The question is, why don't systems and libraries treat TAI as the first-class citizen of timekeeping? Why aren't we doing it right now? Because it's incompatible with Unix time, or it's something else?
The number of seconds since January 1. 1970 UTC.
Even if UTC counts the same second twice, this does not change how many seconds has elapsed since the unix epoch.
If you click through the articles reference to wikipedia and again from there, you will end up on "The Open Group Base Specifications Issue 7, 2018 edition"
> The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified.
Which again sounds like there is absolutely no reason to double count or skip seconds in unix time.
However, I am not quite sure of the implication of the formula written there, but I fear that it says that the number of seconds since the epoch is defined, not as the number of seconds since the epoch, but by the UTC definition of the current time.
The original article said,
> Each Unix day has the same number of seconds, so it can’t just add an extra second – instead, it repeats the Unix timestamps for the last second of the day.
Your POSIX link says,
> As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds.
I'm not a expert on timekeeping, but it appears the only problem here is that the Unix time is bounded by a 86,400-second day, which I guess was meant to make a Unix day predictable, so we still have to double count or skip seconds. It seems the only thing we need to make Unix time monotonic is simply removing the 86,400 seconds Unix day from specification.
On the other hand, it means a Unix day would be unpredictable and it would be impossible to calculate a Unix time without a database, and difficult calculate future Unix time using calendar time. So TAI doesn't automatically solve every problem, everything comes with a tradeoff.
But I think a unpredictable Unix day should be fine for purpose of an internal system clock, so perhaps it's still not a bad idea.
The change to UTC to include leap seconds was in 1972, which was after unix time came into existence.
Also, the fact that Unix time starts before leap seconds were introduced made timekeeping in TAI an even stronger point. And I'm waiting for some insights on why it's not being done.
Unix Time actually never goes backward: it just stagnates during a leap second. The article uses fictional fractional second to argue the contrary but I don't think it makes much sense. Unix Time is represented an integer and has no concept of such a fractional unit.
That's an important distinction because it means that if you use Unix Time as a timestamp you can actually be sure than an event with a smaller stamp happened before. You can't say anything about the ordering of events having the same timestamp but that remains true with or without leap second.
Is your concern over weather Unix Time is a time_t or a timeval?
A time_t shouldn't go backwards (in normal operation), but a timeval does.
Yes, you could put it that way. I view Unix Time as referring strictly to the time_t part (seconds since Epoch) but I might be the one in the wrong. I didn't remember that the timeval part existed in the standard.
gettimeofday gives you a struct timeval with microsecond resolution.
clock_gettime (which takes an extra argument specifying which of several clocks to use) gives you a struct timespec, with nanosecond resolution.
Still, unless you actively mess with, Unix Time actually never goes backward.
The consequences show up in large ways, as well, especially in distributed systems. Calculating an order of events, for instance, based on some notion of time is an obvious flaw. Even within a single system, assuming that a time stamp can be relied on to indicate order of events is wrong.
If you work in domains where these things are important you will eventually come to understand that simplistic and naive statements such as "unix time never goes backwards" are the swords that programmers eventually fall upon.
> If I wait exactly one second, Unix time advances by exactly one second
How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 seconds.
I feel like this is wrong too:
> If there’s a leap second in a day, Unix time either repeats or omits a second as appropriate to make them match.
It's not Unix time doing that. It's UTC.
Im pretty sure the second graph is mislabeled (the UTC second after 23:59:60 should be 00:00:00), but Unix time takes 23:59:60 to mean the same as 00:00:00. So 23:59:60.5 is also the same as 00:00:00.5, and so on. If you parsed the Unix time into a readable timestamp, it would tell you it's the first second of the next day for two seconds.
No, but it means UNIX time does not advance by exactly one second per elapsed second. Instead it advances by either 0 or 2.
> It's not Unix time doing that. It's UTC.
It's also unix time. unix time is (86400 * days_since_epoch + seconds_since_midnight). A leap second means a day is not 86400 seconds, and thus you'll either get a skip or a repeat on midnight rollover.
The OP did not make this claim. He said that waiting 1s does not necessarily increase the Unix time by one second - not the other way around.
Or how my highschool math teacher put it: Every time it rains, the street gets wet. But not every time the street is wet, it rained - maybe my dog just took a leak....
I.e. disconnect from a time server for a few days/weeks/months/etc. When you reconnect, it could be off by seconds/minutes/hours. Odds are pretty good that your system will just jump to the correct time immediately, rather than smearing it out for like N*3x longer than the difference is.
The same is true any time you lose your internal clock, e.g. if your machine is shut down and its battery dies. If it were to skew across "all time since jan 01, 1970", it'd probably catch up well after the expected lifetime of the computer.
POSIX (and ISO) time_t is not supposed to "see" the additional leap second at all. POSIX time_t is defined to effectively always have exactly 86400 seconds per day, and no fractional parts. The seconds as defined by POSIX then can't last exactly as long as the atomic seconds. Even on the days where a leap second occur.
Wikipedia article confirms:
"Every day is treated as if it contains exactly 86400 seconds"
But that the seconds don't last the same and therefore aren't "the same" like the "atom clock" seconds should not matter for the normal users.
The graphs in the article with the fractions of the second going backwards are just poor implementations in some specific operating systems, libraries or programs. It's not something that POSIX standard prescribes that is supposed to happen.
The confusion of the common programmers, like the writer of the article or those who implemented the "backwards" behavior comes from them not understanding what they work with. Most of the users of most of the computers don't have atomic clock. So they also can't count atomic clock seconds. What the "normal" computers have are clocks which are much less precise. It's exactly for that kind of use the time_t is designed by POSIX to have exactly 86400 seconds per day -- the absolute error is at most one "atomic" second per c.a. half a year, but the error of all of the clocks directly available to the normal users in their normal computers is bigger.
So "normal" programs which do common human-related scheduling should not even try to care about the leap second. Use something like a "smeared" time as a reference:
The SI seconds in that article are the "real atomic clock seconds" -- but caring about them isn't even needed for normal human related computing tasks. If you have a real atomic clock, by all means synchronize it with other atomic clocks. If you have a normal computer, use the smeared time. There will be no "jumps" at all then.
Leave the leap second to the astronomers and others who are doing the "hard" time tasks, they have to care, and they have their own software for that.
"the duration of 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium-133 atom" (at a temperature of 0 K)" https://en.wikipedia.org/wiki/Second
That SI second is what I refer to when I mention an "atomic clock second."
The time_t second is effectively simply one 86400th of a day.
Our solution was simple: temporarily pause all the auctions :)
We already had site-wide "auction pause" code as a result of people DDOS'ing the site.
Everything went as planned on our side of earth. But our local asian in Japan, managing several colocations in Asia (Jp/hk/singapore/india...) were thinking this leap second was at midnight LOCALTIME.
I just remember the mess they had to deal with, the day after. Cause midnight UTC is not midnight in Japan, hft is over sensitive to time coordination. shifting forward or backward 1sec can close your connection to market.
There are topics in which the ordinary or common sense understanding of a thing actually interferes in understanding how that topic actually acts in reality when looked at closely or under complex conditions.
The concept of time is one of those things. The best thing a naive developer can do when reasoning about time is to first know that almost everything they assume is wrong, and they don't even know what their assumptions are.
The concept of 'location' is another of these topics.
I would like to close this comment with a helpful link to a concise introduction for people to start with in clearing out the 'common sense' assumptions but I haven't ever found one, and haven't invested enough time to write one. Sorry. Links to same will be gratefully received.
* Every standard library needs properly implemented and properly documented functions for converting between UTC and TAI.
* NTP should (at least optionally) tell the user TAI and UTC (like GPS already does).
* When mounting a legacy file system there should be an option to specify whether timestamps should be interpreted as TAI or UTC.
* New filesystems should have a field that specifies TAI or UTC. It would probably be a single bit for the whole filesystem rather than per timestamp.
* The CLOCK_UTC proposal should be implemented, with tv_nsec in the range 1000000000 to 1999999999 during a leap second.
Humans are also "wrong" but happy with that, celebrating birthdays indepenent of timezones. Some celebrate birthdays independente of the actual date birth occured like the Queen or Jesus or anyone born on the 29th of feb.
Far more likely your clock goes backwards because you fuck up your ntp config than any other reason.
Einstein showed us seconds aren't seconds anyway, unless you happened to have the same inertial frame.
Posix defers to ISO C where they differ: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
See page 391. The encoding of Unix time is explicitly unspecified there.
Posix goes on to say: http://pubs.opengroup.org/onlinepubs/9699919799/
“ The time() function shall return the value of time [CX] [Option Start] in seconds since the Epoch. [Option End]”
So, Unix time is optionally seconds since the epoch, with no further guidance about leap seconds.
Also, the spec makes it clear that time_t needs to be converted into the appropriate time zone, which suggests it does not reflect leap seconds.
I’d be convinced by source code or documentation for both BSD and Linux showing they’re intentionally not posix compliant on this front, and apply leap seconds to Unix ticks and not their time zone conversions.
There's a more insidious problem here - that a computer's internal representation of a second actually falls in line with an actual second. Quartz clocks are, at best, approximations. Temperature adjusted approximations at that.
Without NTP and its ilk, computers would be a complete disaster when it comes to keeping regular time.
And it has done so for probably at least ten or fifteen years.
Unix time assumes that each day is exactly 86,400 seconds long (60 × 60 × 24 = 86,400), leap seconds be damned
- Hardware clocks track Terrestrial Time, and TT is used for timestamps and all timekeeping that doesn't care about where exactly on the planet you are
- Leap seconds are treated as part of the timezone data. UTC is treated as just another timezone, with the appropriate leap second offset given by the timezone data for that date and time
- NTP keeps hardware clocks synchronized to TT and also carries updates to timezone data (including leap seconds)
This doesn't solve the problem of hardware clocks jumping backwards or forwards in time - hardware clocks can drift or be misset etc. and be updated - but I can't help but thinking that much of the pain around time and timezones is caused by basing our timekeeping on UTC rather than TT.
So my team was testing a system with some devices, one of which was a GPS and the main system had UTC from NTP. We had a big display that showed all our data including both times, so we could monitor what was going on. So the two displayed times were 13 seconds apart (the number of leap seconds then). Our program manager was a smart guy but gaffe prone. So in a demonstration of our system he blurted out to the whole room of observers, 'hey something is wrong, those two times are different'. We cringed and explained, but it sounded like we were covering up an error. But he would go on to repeat the gaffe again to a different group.
If such standard existed, wouldn't it be the best to use for programming, with "simple" conversions to/from the all the other standards?
Basically, I want a monotonic clock that starts at an arbitrary point (I would suggest Isaac Newton's birthday), is able to go all the way back to the big bang, and forward until the heat death of the universe, with millisecond or better precision.
Unix time is set up to allow programmers to assume every day has the same number of seconds. Is this the best approach, or would it have been better to try to educate everyone not to make that assumption and to use a standard library for all UTC calendaring?
Cultural time is fine and dandy for human level stuff. Keep that simple. Scientific time for business, engineering and scientific stuff.
Business and engineering are chock-full of human-level stuff. And scientific stuff which isn't either doesn't use UTC (astronomy) or is not impacted (because it deals pretty much only with sub-day durations and everything works based on the SI second only).
I don't know if there are libraries that can handle leap seconds or is everyone just counting on NTP sync fixing things whenever a leap second occurs.
That does not and can not work when trying to represent future local events, which is the vast majority of them as an event normally happens relative to a specific geodesic location.
Astronomical events are more or less the only ones which actually routinely get planned in TAI / TT, and astronomical software is thus the only one for which this model could actually work. And then you wouldn't be using unix timestamps (because it's UTC).
Here are 20 more links: https://github.com/kdeldycke/awesome-falsehood#dates-and-tim...
Emprically it seems to be after but that seems wrong; shouldn’t the result of the command be the same regardless of how long it takes to type the sudoer’s pw?
I think it’s okay to say that these things are generally true with exception of leap seconds. Leap seconds don’t make these statements untrue.
No-one uses the Olson "right" TZ data files.
What is stated in M. Chan's article is only true when using the "posix" TZ data files. But that's not the only option.
Is it hard coded in there somewhere?
In other news: most software is brain-dead and most software engineers lack basic education in pretty much everything other than composing tons of terminally boring code out of a few LEGO shapes provided by programming languages.
> Unix time is the number of seconds since 1 January 1970 00:00:00 UTC
Is true regardless of the calender or leap seconds. Think of seconds in terms of some physical phenomena, like how many times a certain atom trapped in a crystal lattice vibrates and you see that doesn't depend on the calendar. Converting Unix time to local time obviously has to take that into account, but we still need an absolute measure of our progress does the timeline which is what Unix time provides.
This is why we use Unix time, it's the same everywhere and nothing short of relativity can affect it.
> Think of seconds in terms of some physical phenomena, like how many times a certain atom trapped in a crystal lattice vibrates and you see that doesn't depend on the calendar
Unix time is NOT the number of physical seconds since 1970 UTC. It's the number of Unix Seconds since 1970. Every day has 86400 Unix Seconds. Some UTC days have more than 86400 physical days. Unix time cannot represent the seconds beyond 23:59:59 on a UTC day, but otherwise attempts to match UTC.
> Every day has 86400 Unix Seconds.
Except a day with a leap second in it.
> Unix time cannot represent the seconds beyond 23:59:59 on a UTC day, but otherwise attempts to match UTC.
Err...it literally represents ~49 years beyond 23:59:59 on Day1 of UTC.
How about the UTC seconds before and after that one, 1985-06-30 23:59:59 and 1985-07-01 00:00:00? My understanding is that the first is 489023999, and the second is 489024000.
There is one unix second, but two physical seconds between the start of the two times.
That's not a physical second, it's a calendar second.
On most days, every unix second corresponds with exactly one UTC second and they all correspond with exactly one physical second, and each one could be measured as the number of vibrations of some particular atom.
On a day with a positive UTC leap second, it's different. At 12:00:00 UTC, it's 12:00:00 unix time, the next day at 12:00:00 UTC, it's also 12:00:00 unix time; 86401 physical seconds have passed, and UTC has counted 86400 calendar seconds, one of which was a leap second, but unix has only counted 86400 seconds.
If you're running leap smearing, all of the unix seconds in that day are a little bit longer than the physical seconds (the exact details depending on your smear technique). If you're using classical techniques, 23:59:59 will be two physical seconds long, and the fractional second will reset to zero as the second physical second starts and count up again.
In contrast to UTC, and Unix Time, TAI always has exactly 86400 physical seconds per day, but after a UTC leap second, both UTC and Unix Time will be offset from TAI by an additional second.
UNIX time does not represent/reference calendar time, it represents the number of physical seconds since 1970-01-01UTC. How you translate that into local calendar time is up to you!
The leap seconds added in 2005, 2008, 2012, 2015, and 2016 are all uncounted there. If Unix timestamps were the count of physical seconds that had passed since 1970/1/1 UTC, then the end result of my test should have been 599529605 instead of 599529600.