20 ms·

Falsehoods programmers believe about Unix time

442 points by pplonski86 7y ago

turtlegrids 7y ago
Love it. You will continue to capture my heart and my upvotes whenever you post anything about the many nuances of storing and representing time. Or something about Unicode / character sets.
dintech 7y ago
tl;dr: you should know about leap seconds.
koala_man 7y ago
> But it’s unsatisfying to say “this is false” without explaining why 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.
- TeMPOraL 7y ago
  Is this really a problem? The "falsehood programmers believe" articles I remember reading all list things that were either obvious, or obvious in retrospect.
  - deathanatos 7y ago
    I disagree about obvious. Some are not, IMO, obvious, and some are actually true within reasonable bounds. From one of the previous lists[2]: > 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[4].) > 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[3] 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[1] 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. [1]: https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_calendar https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_cale... [2]: http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time http://infiniteundo.com/post/25509354022/more-falsehoods-pro... [3]: https://docs.oracle.com/javase/7/docs/api/java/util/GregorianCalendar.html#setGregorianChange(java.util.Date) https://docs.oracle.com/javase/7/docs/api/java/util/Gregoria... [4]: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
  - koala_man 7y ago
    Take the original one about names, which claims that sometimes children don't get names. 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.
  - Semiapies 7y ago
    Yes. Only a small minority of Falsehoods articles so much as point people at resources to relevant resources, much less find better practices. Fewer back up their claims. The Falsehoods listicles that were actually obvious were Falsehoods Most Programmers Don't Actually Believe.
  - jillesvangurp 7y ago
    The artcicle is confusing unix time, which is an integer that increments every second, with it's UTC representation. This representation is an interpretation of that number. In theory it could be decremented. But this has never happened. In practice what happens is that we add leap seconds, which means that we allow the UTC interpretation of the incrementing integer to have an extra second and not that we move the integer forward by two seconds. 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.
- duxup 7y ago
  I blame (perhaps unfairly) this idea that people write a lot of programming related articles and blogs as resume fodder, and not really for an audience beyond that. 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...
  - kosievdmerwe 7y ago
    Talking about resume fodder, my favorite is how everyone seems to have to write an article about bloom filters. Or at least every month or so someone posts an article about them on HN from their blog[1]. They're a brain dead simple data structures and a lot of times the author leaves off the actual hard bit about them: deciding how big they should be and (after reading up about them a bit while writing this comment) how many hash functions they should have. [1] https://hn.algolia.com/?query=bloom%20filters&sort=byDate&prefix&page=0&dateRange=all&type=story https://hn.algolia.com/?query=bloom%20filters&sort=byDate&pr...
- Semiapies 7y ago
  Yeah, the standard falsehoods listicle would have ended right before that line. Timekeeping is strange. Makes me want to store everything in TAI and then convert it for display.
  - wglb 7y ago
    As is done in qmail.
    - Semiapies 7y ago
      Interesting—I wondered if anyone was doing that.
- waynecochran 7y ago
  This is all over dramatized myth busting -- one could simply say they are all true except for the occasional leap second adjustment. No need for the dramatic "they are all false."
  - bradknowles 7y ago
    Everything is true, except when it's not. ;)
rkapsoro 7y ago
I found this out some years ago and for some reason I felt a profound sense of betrayal. :D
RcouF1uZ4gsC 7y ago
One thing to note is that both Google and Amazon smear out the leap seconds https://developers.google.com/time/smear https://developers.google.com/time/smear so that this is no longer a falsehood on AWS or GCP. I suspect, over time, more organizations will adopt this approach.
- dooglius 7y ago
  Leap smearing makes #3 no longer false, but #1 and #2 remain false
  - Groxx 7y ago
    Also worth noting that even tho it "solves" leap seconds, it does nothing to solve normal clock corrections. Clocks skew normally, and they need to be corrected eventually - nothing that I'm aware of skews across more than a couple seconds / within NTP limits. 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.
rusbus 7y ago
Is it also possible for Unix time to go backwards with NTP? I assume that's much more common in practice than leap seconds?
- aflag 7y ago
  ntpd will only move the clock backwards if the gap is too big and you run a command. Otherwise, it will only slow down the clock and possibly alert you that it's having trouble catching up.
ramshorns 7y ago
Falsehood #2 is false even for inserted leap seconds. If you wait one second from 23:59:60.00 to 00:00:00.00, Unix time has advanced by zero seconds.
jlv2 7y ago
The author uses graphs with quarter-second increments because they make it look weirder. It's not that weird for time to standstill for 1 second.
- airstrike 7y ago
  Who cares if we're off by 1 second so long as we're all off by the same amount? Maybe we should all wait until this lag adds up to 1 minute before we adjust things instead of perpetually reaching for abstract perfection
  - isostatic 7y ago
    Or conversely why don't we add leap deciseconds, or centi or milliseconds?
    - bloak 7y ago
      It seems to me that the one-second adjustment is exactly the right compromise. It's small enough to be ignored for most practical purposes (many clocks are out by a second anyway), and it means that the offset between TAI and UTC is a round number (37 s rather than 36.852 s), while leap seconds are frequent enough for people to get a bit of practice at handling them, while rare enough that you can avoid them if you're not confident about handling them: don't schedule any rocket launches for 00:00 on Jan 1 or Jul 1. It seems exactly right to me.
- Dylan16807 7y ago
  It is when your video and audio buffers needs to be updated 60 and 200 times a second. And it'll cause all kinds of exciting effects on databases or very active network connections.
speleo_engr 7y ago
I read articles like this and come to the conclusion that UTC is flawed, not Unix time. Leap seconds seem mostly useless. People seem to think they are important for astronomy, but for every astronomical calculation I have ever done, your first step is converting from UTC to TAI. Move any jumps in time to once a century (or millennium). Such jumps have occurred in the past (Julian to Gregorian) and are easy to handle programmatically. People think time increases monotonically and it's confusing to push it any other way. 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.
- jordanpg 7y ago
  This made me think of time in science fiction, eg. https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interstellar_culture https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interste.... On a long enough horizon, I take it as a foregone conclusion that simple metric measurements will become standard.
- labster 7y ago
  Leap seconds are useful if you're an astronomer. Astronomers have always determined the current time. Therefore, we all get leap seconds.
  - planteen 7y ago
    How are leap seconds useful if you are an astronomer? I am genuinely curious what problem in the year 2019 is easier due to leap seconds. 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: https://www.willbell.com/math/MC1.HTM https://www.willbell.com/math/MC1.HTM
    - someguydave 7y ago
dev_dull 7y ago
> Unix time is the number of seconds since 1 January 1970 00:00:00 UTC > If I wait exactly one second, Unix time advances by exactly one second > Unix time can never go backwards 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.
BentFranklin 7y ago
A whole second of leap? So grainy. Planck scale or go home.
nulagrithom 7y ago
I don't understand this one: > 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.
- seaish 7y ago
  Unix time is based on a hard calculation of UTC seconds, minutes, hours, days, and years. So UTC jumping causes a discontinuity in Unix time. 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.
- Groxx 7y ago
  UTC jumping around affects it if you're basing your time-elapsed measure by checking "time.now() - previouslySavedTime". That can give you a negative value, if e.g. your 1/2-second elapsed time crossed a leap second.
- jlg23 7y ago
  > How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 seconds 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....
- masklinn 7y ago
  > How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 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.
teknopaul 7y ago
A reality that most of these types of blog dont mention is that you may well not have any applicable data. E.g. users registered before 2000. Or any dates at all that care about second precision. 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.
deleted 7y ago
[deleted]
xeeeeeeeeeeenu 7y ago
Windows (since recently) is probably the only operating system with an actual leap seconds support: https://techcommunity.microsoft.com/t5/Networking-Blog/Top-10-Networking-Features-in-Windows-Server-2019-10-Accurate/ba-p/339739 https://techcommunity.microsoft.com/t5/Networking-Blog/Top-1...
- lelf 7y ago
  https://www.freebsd.org/cgi/man.cgi?query=posix2time https://www.freebsd.org/cgi/man.cgi?query=posix2time
lcuff 7y ago
These are nasty little corner-cases. I do wonder if the first two are worth worrying about: For (1) I can't see a use-case where it would be important. For (2) Timing of this granularity is likely going to be done through nanosleep() and the POSIX.1 specification says that discontinuous changes in CLOCK_REALTIME should not affect nanosleep(). For (3) smearing, as Google and Amazon do, will handle it, as pointed out by others: https://developers.google.com/time/smear https://developers.google.com/time/smear
brmgb 7y ago
I deeply disagree with point 3. 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.
- jhayward 7y ago
  You can set unix time to any value, including the future or past. If timestamps are recorded during those time-traveling epochs you will indeed see time go backward. Anyone writing time-aware processing needs to take this in to account, or they will eventually suffer for it.
  - brmgb 7y ago
    Sure, you can manually force Unix Time to go backward but that's very different from what is argued in the article. If you do time-aware processing and mess with the clock you are using, you can except troubles. That's in no way unique to Unix time. Still, unless you actively mess with, Unix Time actually never goes backward.
    - jhayward 7y ago
      It happens all the time. Go talk to ops/sre types who run large fleets and ask them for their time stories, also ask them how much infrastructure and scaffolding they have to have in place to ensure that such things are as rare as possible. 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.
yanowitz 7y ago
chrony[1] neatly solves these and a host of related issues by guaranteeing time increases monotonically on a given host, speeding up or slowing down the clock appropriately. It's a nicer alternative to ntpd. Also, AWS recommends it if you are using their Time Sync service (which is GPS-locked atomic clocks in every region with leap second smearing). [1]
- bradknowles 7y ago
  The Reference Implementation of NTP from ntp.org will do clock skewing by default, if the offset is within certain limits of reasonableness. And it has done so for probably at least ten or fifteen years.
- cat199 7y ago
  > It's a nicer alternative to ntpd. define nicer?
  - astrange 7y ago
    ntpd is a pretty weird daemon in the same way that bind is. The config format is insecure and impossible to understand; if you try to change it you'll probably break it.
falcolas 7y ago
> If I wait exactly one second, Unix time advances by exactly one second 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.
tus87 7y ago
This guy is confusing Unix time with local time. This statement: > 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.
- aflag 7y ago
  Are you saying Unix time doesn't get adjusted when there are calendar changes in the box?
  - tus87 7y ago
    Correct. When was the last time you changed UNIX time due to summer time/daylight savings?
    - aflag 7y ago
      It follows UTC, so that doesn't apply. From what I understand, it does follow things like leap seconds, though.
- toast0 7y ago
  > > Unix time is the number of seconds since 1 January 1970 00:00:00 UTC > 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.
  - 7y ago
derefr 7y ago
Question: would anything go wrong on a Unix system if you used TAI as your timezone, rather than UTC? TLS, maybe?
- toast0 7y ago
  TLS doesn't care about a 30 second difference in clocks, unless you're running your certs really close to the notBefore/notAfter. There's enough broken systems out there that it makes sense to not use certs that don't have at least 24 hours of margin on either side.
jhayward 7y ago
One thing that this article evokes is the 'I'm wrong and my belief is deeply held' aspect which technology people occasionally fall in to. Looking at the comments, with incorrect beliefs expressed as dicta ranging from just plain wrong, to incompletely specified, to ordinary confusion is giving my tech-PTSD a workout. 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.
AgentME 7y ago
Here's a falsehood I've seen a bunch of times: the idea that Unix timestamps need to be converted to your local timezone. Unix timestamps are the number of seconds since a specific date in a specific timezone (UTC)! If a user gives you a Unix timestamp and you know they're in the PDT timezone, you should not add or subtract 7 hours of seconds to "convert" the timestamp to UTC! It already is. Similarly, if your client receives a Unix timestamp from your server, you shouldn't modify the Unix timestamp to "convert" it to your user's local timezone. Unix timestamps are always UTC. Your platform's date handling APIs should already offer a way to display a Unix timestamp in the user's timezone or an arbitrary one, and maybe even have a class that represents a Unix timestamp paired up with a specific timezone. At no point should you be doing arithmetic on the Unix timestamp portion to convert it between timezones.
- Florin_Andrei 7y ago
  > Here's a falsehood I've seen a bunch of times: the idea that Unix timestamps need to be converted to your local timezone. That's less of a "falsehood", more of a complete misunderstanding of what Unix time is.
  - rhizome 7y ago
    Yep, a faulty belief is not the same as ignorance.
  - AgentME 7y ago
    I think it's a common misunderstanding worth bringing up here that probably affects more people than the falsehoods listed in the article. On roughly 3 out of the 4 times I've had a coworker run into a timezone issue (different person each time), their first impulse was to do something like what I described. (I stopped them early most of the times, so maybe they would have figured out it was the wrong way to go about it.) 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.
- 7y ago
abtinf 7y ago
Perhaps a stupid question: Why isn't there a time standard that is monotonic and defined simply in terms of seconds, without attempting to match the movement of the earth (no leap seconds, no negative seconds, no daylight savings, no complicated calendar politics)? 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.
- msla 7y ago
  TAI is what you want.
- deleted 7y ago
  [deleted]
- spydum 7y ago
  I can’t WAIT until we have to deal with time dilation problems on networks and certificates.
- brlewis 7y ago
  Not a stupid question...it's the central question here. 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?
alanfranz 7y ago
So, if I adopt smearing for my NTP, everything works fine.
- bradknowles 7y ago
  Except then, a second isn't actually a second.
  - lodi 7y ago
    But that's always true anyway because of clock drift, skew, etc. Otherwise we wouldn't need NTP in the first place.
  - paulddraper 7y ago
    But it pretty much is. Einstein showed us seconds aren't seconds anyway, unless you happened to have the same inertial frame.
legohead 7y ago
I was aware of leap seconds after working for an online auction website. How to deal with all the auctions that may be ending right at or before the leap second? 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.
- netmonk 7y ago
  Well, well i was working in a major bank, in HFT dpt. We had team all over the world. Our cisco switch were not able to deal correctly with leap second, so basically we had to switch them off just before the leap second, and switch them back on, right after. 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.
martovmarkov 7y ago
Can this cause another "millenium bug" chaos again?
tinix 7y ago
time is hard: https://gordol.github.io/date_time_manipulation.html https://gordol.github.io/date_time_manipulation.html
netmonk 7y ago
for those interested in this kind of topics, i cannot recommand more than suscribe to the timenuts mailing list : http://leapsecond.com/time-nuts.htm http://leapsecond.com/time-nuts.htm
revicon 7y ago
Unix time assumes that each day is exactly 86,400 seconds long (60 × 60 × 24 = 86,400), leap seconds be damned I don't think I understand this claim. Unix time has no concept of a "day". Leap seconds increment UTC time, but doesn't add anything to the number of seconds that have elapsed since unix epoc.
- nemetroid 7y ago
  That's one of the falsehoods. Unix time is not equal to the number of elapsed seconds since the epoch, it is equal to N x 86400 + s, where N is the number of days that have elapsed since the epoch, and s is the number of seconds that have elapsed since midnight.
alpb 7y ago
There are much longer lists about this, like: https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b... Here are 20 more links: https://github.com/kdeldycke/awesome-falsehood#dates-and-time https://github.com/kdeldycke/awesome-falsehood#dates-and-tim...
anilakar 7y ago
Another falsehood, altough it goes against the POSIX standard: the epoch is midnight in UTC. There is at least one obscure Unix-like OS (can't remember the name) where the epoch is 1970-01-01 in local timezone
acqq 7y ago
The article is wrong or misleading. 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: https://developers.google.com/time/smear https://developers.google.com/time/smear 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.
- FabHK 7y ago
  Agree. In other words, computers should use UT1 (where one day is a rotation of the earth, and 86400 seconds; and consequently a second is not a SI second).
  - acqq 7y ago
joeleisner 7y ago
Never knew about this... interesting article!
PureParadigm 7y ago
Leap seconds definitely add way more complexity/uncertainty when dealing with timestamps in the future. I once made a program that would output the amount of time remaining until some time in the future (with the future time represented as a Unix timestamp). I realized that it is simply not possible to report the number of seconds until an event >6 months in the future because we simply don't know if there might be a leap second or not between now and the time in the future. Perhaps the best approach for users would be to smear any leap seconds that are announced so it never has a hard jump, but it's still not ideal because if you really want to count down to the future time you simply can't.
dmh2000 7y ago
just an anecdote about UTC vs GPS time. GPS time doesn't have leap seconds. 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.
JdeBP 7y ago
A falsehood that Alex Chan believes about UNIX: 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. * https://unix.stackexchange.com/a/327403/5132 https://unix.stackexchange.com/a/327403/5132 * https://unix.stackexchange.com/a/334029/5132 https://unix.stackexchange.com/a/334029/5132 * https://unix.stackexchange.com/a/294715/5132 https://unix.stackexchange.com/a/294715/5132
Kenji 7y ago
> If I wait exactly one second, Unix time advances by exactly one second, unless a leap second has been removed. What complete and utter bogus. Just because some moron in the IERS has defined that my day has more or less seconds doesn't mean time stands still for me. If I wait 1 second in UNIX time, one second passes. As in: If I am travelling at 1 meter per second, and I wait one second in UNIX time, I travelled one meter. Maybe UTC didn't advance but time in the real, actual world advanced. The ground truth is UNIX time which advances monotonically and linearly. UTC is a political garbage mess plopped on top of actual time. So, on the graph you've got it the wrong way around: The x-axis should be UNIX time, the y-axis should be UTC time.
diminoten 7y ago
> So far, there’s never been a leap second removed in practice (and the Earth’s slowing rotation means it’s unlikely) Oh, okay. Thanks!
- chithanh 7y ago
  Earthquakes and other geological events can speed up rotation though, but so far never enough to remove a leap second.
tqwhite 7y ago
Unix time is the humber of seconds since 1970. Seconds are a physical thing. Unix time references the number of "cycles of the radiation produced by the transition between two levels of the cesium 133 atom" UTC measures time. This article is silly.
- masklinn 7y ago
  > Unix time is the humber of seconds since 1970. It's not, and it has never been. The original unix time was "the time since 00:00:00, 1 January 1971, measured in sixtieths of a second", this got modified multiple times until it settled upon the number of UTC seconds since 1970-01-01T00:00:00Z, meaning it's non-monotonic, non-continuous, and not based on "physical" seconds.
bcaa7f3a8bbc 7y ago
The original purpose of Unix time was decoupling local time representation and internal timekeeping of the system. Unix time could be the "One True Time" of the system, it always increases monotonically. When you need local time, all the tricky and nasty details, including DST, mandated calendar changes, etc, are processed by the tzinfo system library/database. If the calendar has changed, at least in principle one does not and should not have to update the system clock or most unrelated applications, simply update tzinfo and you're done. 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?
- nitwit005 7y ago
  > Unfortunately, Unix time did not considered the effects of leap second The change to UTC to include leap seconds was in 1972, which was after unix time came into existence.
  - bcaa7f3a8bbc 7y ago
    It has nothing to do with my argument, there could be awareness, to the extents that Unix architects had seen it in the news, but still, it was not considered. I don't believe support of leap second was built into Unix and honored properly until 1990s, when NTP became prevalent. 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.
- wodenokoto 7y ago
averros 7y ago
Basically, everyone who has a clue about time standards uses TAI for internal representation in non-relativisitic applications. 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.
- averros 7y ago
  ...oh, and there's also the issue of time domains and time sources having different spectral shapes of their noise.
osrec 7y ago
So when we convert Unix time to Y-m-d format, are those conversion algorithms aware of the leap seconds? Is it hard coded in there somewhere?
dkbrk 7y ago
Perhaps I don't fully understand the reasoning that went into these things when they were decided, but I think the following would be more sane: - 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.
max76 7y ago
I think we should have a scientific definition of time -- something that is highly static and precise (such as the time it takes for an atom to vibrant a number of times, or the time it takes light in a vacuum to travel a certain distance) and a cultural definition of time that is more loose than UTC (There is always the same number of seconds in a day, but maybe some days have shorter seconds than other days). Cultural time is fine and dandy for human level stuff. Keep that simple. Scientific time for business, engineering and scientific stuff.
- brianpan 7y ago
  Time might not be too hard to define (relativistic effects aside), but the problem is days and years. The reason for inserting and removing seconds is because the rotation of the earth is NOT static and precise. It changes so seconds are added and removed to keep the day from drifting. https://en.wikipedia.org/wiki/Day_length_fluctuations https://en.wikipedia.org/wiki/Day_length_fluctuations
- masklinn 7y ago
  > Cultural time is fine and dandy for human level stuff. Keep that simple. Scientific time for business, engineering 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).
xucheng 7y ago
To see the current value for different time standards (e.g. UTC, GPS, TAI): http://leapsecond.com/java/gpsclock.htm http://leapsecond.com/java/gpsclock.htm
gauravphoenix 7y ago
a fun command to run: cal 9 1752
dancek 7y ago
I've been thinking about datetime APIs and how most of them become extremely tedious when you have to account for daylight saving, countries changing time zones et cetera. I was actually planning to write my own implementation for $language using unix timestamps as internal representation and requiring a timezone whenever parsing or printing. But then I considered leap seconds. 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.
- masklinn 7y ago
  > I was actually planning to write my own implementation for $language using unix timestamps as internal representation and requiring a timezone whenever parsing or printing 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).
  - dancek 7y ago
    Yes. Almost everything is subtly broken, and I realized my attempt would be broken too. Didn't feel like a fun hobby project once I realized that.
kstenerud 7y ago
This is why I use smalltime when storing time values. https://github.com/kstenerud/smalltime https://github.com/kstenerud/smalltime
unhammer 7y ago
http://yourcalendricalfallacyis.com/ http://yourcalendricalfallacyis.com/
time_travlr 7y ago
Why does Unix time first travel forward one second, then go backwards one second, versus "pausing" (flat line on the graph) one second? Both have their pros and con; if the graph accurately depicts how Unix time is implemented, why was this decision made versus the other?
bloak 7y ago
Having spent some time studying time keeping in computers, I've come to the conclusion that nothing needs to be changed. In particular, UTC is exactly what it should be and should be left as it is. However, there are some things that need to be added: * 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.
hedora 7y ago
I’m not convinced this article is correct. Posix defers to ISO C where they differ: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf 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/ 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.
rlucas 7y ago
My Unix time question is, when I do “sudo date <DDMMhhmmyyyy>” and then get a sudo password prompt, is the time supposed to take effect before or after the sudo is authenticated? 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?
- bheiskell 7y ago
  After, because sudo won’t run any command until it authorizes that you’re allowed to run the command.

442 points by pplonski86 7y ago

Love it. You will continue to capture my heart and my upvotes whenever you post anything about the many nuances of storing and representing time. Or something about Unicode / character sets.

dintech 7y ago

tl;dr: you should know about leap seconds.

koala_man 7y ago

> But it’s unsatisfying to say “this is false” without explaining why 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.

TeMPOraL 7y ago
Is this really a problem? The "falsehood programmers believe" articles I remember reading all list things that were either obvious, or obvious in retrospect.
- deathanatos 7y ago
  I disagree about obvious. Some are not, IMO, obvious, and some are actually true within reasonable bounds. From one of the previous lists[2]: > 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[4].) > 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[3] 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[1] 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. [1]: https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_calendar https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_cale... [2]: http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time http://infiniteundo.com/post/25509354022/more-falsehoods-pro... [3]: https://docs.oracle.com/javase/7/docs/api/java/util/GregorianCalendar.html#setGregorianChange(java.util.Date) https://docs.oracle.com/javase/7/docs/api/java/util/Gregoria... [4]: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
- koala_man 7y ago
  Take the original one about names, which claims that sometimes children don't get names. 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.
- Semiapies 7y ago
  Yes. Only a small minority of Falsehoods articles so much as point people at resources to relevant resources, much less find better practices. Fewer back up their claims. The Falsehoods listicles that were actually obvious were Falsehoods Most Programmers Don't Actually Believe.
- jillesvangurp 7y ago
  The artcicle is confusing unix time, which is an integer that increments every second, with it's UTC representation. This representation is an interpretation of that number. In theory it could be decremented. But this has never happened. In practice what happens is that we add leap seconds, which means that we allow the UTC interpretation of the incrementing integer to have an extra second and not that we move the integer forward by two seconds. 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.
duxup 7y ago
I blame (perhaps unfairly) this idea that people write a lot of programming related articles and blogs as resume fodder, and not really for an audience beyond that. 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...
- kosievdmerwe 7y ago
  Talking about resume fodder, my favorite is how everyone seems to have to write an article about bloom filters. Or at least every month or so someone posts an article about them on HN from their blog[1]. They're a brain dead simple data structures and a lot of times the author leaves off the actual hard bit about them: deciding how big they should be and (after reading up about them a bit while writing this comment) how many hash functions they should have. [1] https://hn.algolia.com/?query=bloom%20filters&sort=byDate&prefix&page=0&dateRange=all&type=story https://hn.algolia.com/?query=bloom%20filters&sort=byDate&pr...
Semiapies 7y ago
Yeah, the standard falsehoods listicle would have ended right before that line. Timekeeping is strange. Makes me want to store everything in TAI and then convert it for display.
- wglb 7y ago
  As is done in qmail.
  - Semiapies 7y ago
    Interesting—I wondered if anyone was doing that.
waynecochran 7y ago
This is all over dramatized myth busting -- one could simply say they are all true except for the occasional leap second adjustment. No need for the dramatic "they are all false."
- bradknowles 7y ago
  Everything is true, except when it's not. ;)

rkapsoro 7y ago

I found this out some years ago and for some reason I felt a profound sense of betrayal. :D

RcouF1uZ4gsC 7y ago

One thing to note is that both Google and Amazon smear out the leap seconds https://developers.google.com/time/smear https://developers.google.com/time/smear so that this is no longer a falsehood on AWS or GCP. I suspect, over time, more organizations will adopt this approach.

dooglius 7y ago
Leap smearing makes #3 no longer false, but #1 and #2 remain false
- Groxx 7y ago
  Also worth noting that even tho it "solves" leap seconds, it does nothing to solve normal clock corrections. Clocks skew normally, and they need to be corrected eventually - nothing that I'm aware of skews across more than a couple seconds / within NTP limits. 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.

rusbus 7y ago

Is it also possible for Unix time to go backwards with NTP? I assume that's much more common in practice than leap seconds?

aflag 7y ago
ntpd will only move the clock backwards if the gap is too big and you run a command. Otherwise, it will only slow down the clock and possibly alert you that it's having trouble catching up.

ramshorns 7y ago

Falsehood #2 is false even for inserted leap seconds. If you wait one second from 23:59:60.00 to 00:00:00.00, Unix time has advanced by zero seconds.

jlv2 7y ago

The author uses graphs with quarter-second increments because they make it look weirder. It's not that weird for time to standstill for 1 second.

airstrike 7y ago
Who cares if we're off by 1 second so long as we're all off by the same amount? Maybe we should all wait until this lag adds up to 1 minute before we adjust things instead of perpetually reaching for abstract perfection
- isostatic 7y ago
  Or conversely why don't we add leap deciseconds, or centi or milliseconds?
  - bloak 7y ago
    It seems to me that the one-second adjustment is exactly the right compromise. It's small enough to be ignored for most practical purposes (many clocks are out by a second anyway), and it means that the offset between TAI and UTC is a round number (37 s rather than 36.852 s), while leap seconds are frequent enough for people to get a bit of practice at handling them, while rare enough that you can avoid them if you're not confident about handling them: don't schedule any rocket launches for 00:00 on Jan 1 or Jul 1. It seems exactly right to me.
Dylan16807 7y ago
It is when your video and audio buffers needs to be updated 60 and 200 times a second. And it'll cause all kinds of exciting effects on databases or very active network connections.

speleo_engr 7y ago

I read articles like this and come to the conclusion that UTC is flawed, not Unix time. Leap seconds seem mostly useless. People seem to think they are important for astronomy, but for every astronomical calculation I have ever done, your first step is converting from UTC to TAI. Move any jumps in time to once a century (or millennium). Such jumps have occurred in the past (Julian to Gregorian) and are easy to handle programmatically. People think time increases monotonically and it's confusing to push it any other way. 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.

jordanpg 7y ago
This made me think of time in science fiction, eg. https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interstellar_culture https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interste.... On a long enough horizon, I take it as a foregone conclusion that simple metric measurements will become standard.
labster 7y ago
Leap seconds are useful if you're an astronomer. Astronomers have always determined the current time. Therefore, we all get leap seconds.
- planteen 7y ago
  How are leap seconds useful if you are an astronomer? I am genuinely curious what problem in the year 2019 is easier due to leap seconds. 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: https://www.willbell.com/math/MC1.HTM https://www.willbell.com/math/MC1.HTM
  - someguydave 7y ago

dev_dull 7y ago

> Unix time is the number of seconds since 1 January 1970 00:00:00 UTC > If I wait exactly one second, Unix time advances by exactly one second > Unix time can never go backwards 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.

BentFranklin 7y ago

A whole second of leap? So grainy. Planck scale or go home.

nulagrithom 7y ago

I don't understand this one: > 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.

seaish 7y ago
Unix time is based on a hard calculation of UTC seconds, minutes, hours, days, and years. So UTC jumping causes a discontinuity in Unix time. 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.
Groxx 7y ago
UTC jumping around affects it if you're basing your time-elapsed measure by checking "time.now() - previouslySavedTime". That can give you a negative value, if e.g. your 1/2-second elapsed time crossed a leap second.
jlg23 7y ago
> How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 seconds 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....
masklinn 7y ago
> How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 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.

teknopaul 7y ago

A reality that most of these types of blog dont mention is that you may well not have any applicable data. E.g. users registered before 2000. Or any dates at all that care about second precision. 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.

deleted 7y ago

[deleted]

xeeeeeeeeeeenu 7y ago

Windows (since recently) is probably the only operating system with an actual leap seconds support: https://techcommunity.microsoft.com/t5/Networking-Blog/Top-10-Networking-Features-in-Windows-Server-2019-10-Accurate/ba-p/339739 https://techcommunity.microsoft.com/t5/Networking-Blog/Top-1...

lelf 7y ago
https://www.freebsd.org/cgi/man.cgi?query=posix2time https://www.freebsd.org/cgi/man.cgi?query=posix2time

lcuff 7y ago

These are nasty little corner-cases. I do wonder if the first two are worth worrying about: For (1) I can't see a use-case where it would be important. For (2) Timing of this granularity is likely going to be done through nanosleep() and the POSIX.1 specification says that discontinuous changes in CLOCK_REALTIME should not affect nanosleep(). For (3) smearing, as Google and Amazon do, will handle it, as pointed out by others: https://developers.google.com/time/smear https://developers.google.com/time/smear

brmgb 7y ago

I deeply disagree with point 3. 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.

jhayward 7y ago
You can set unix time to any value, including the future or past. If timestamps are recorded during those time-traveling epochs you will indeed see time go backward. Anyone writing time-aware processing needs to take this in to account, or they will eventually suffer for it.
- brmgb 7y ago
  Sure, you can manually force Unix Time to go backward but that's very different from what is argued in the article. If you do time-aware processing and mess with the clock you are using, you can except troubles. That's in no way unique to Unix time. Still, unless you actively mess with, Unix Time actually never goes backward.
  - jhayward 7y ago
    It happens all the time. Go talk to ops/sre types who run large fleets and ask them for their time stories, also ask them how much infrastructure and scaffolding they have to have in place to ensure that such things are as rare as possible. 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.

yanowitz 7y ago

chrony[1] neatly solves these and a host of related issues by guaranteeing time increases monotonically on a given host, speeding up or slowing down the clock appropriately. It's a nicer alternative to ntpd. Also, AWS recommends it if you are using their Time Sync service (which is GPS-locked atomic clocks in every region with leap second smearing). [1]

bradknowles 7y ago
The Reference Implementation of NTP from ntp.org will do clock skewing by default, if the offset is within certain limits of reasonableness. And it has done so for probably at least ten or fifteen years.
cat199 7y ago
> It's a nicer alternative to ntpd. define nicer?
- astrange 7y ago
  ntpd is a pretty weird daemon in the same way that bind is. The config format is insecure and impossible to understand; if you try to change it you'll probably break it.

falcolas 7y ago

> If I wait exactly one second, Unix time advances by exactly one second 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.

tus87 7y ago

This guy is confusing Unix time with local time. This statement: > 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.

aflag 7y ago
Are you saying Unix time doesn't get adjusted when there are calendar changes in the box?
- tus87 7y ago
  Correct. When was the last time you changed UNIX time due to summer time/daylight savings?
  - aflag 7y ago
    It follows UTC, so that doesn't apply. From what I understand, it does follow things like leap seconds, though.
toast0 7y ago
> > Unix time is the number of seconds since 1 January 1970 00:00:00 UTC > 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.
- 7y ago

derefr 7y ago

Question: would anything go wrong on a Unix system if you used TAI as your timezone, rather than UTC? TLS, maybe?

toast0 7y ago
TLS doesn't care about a 30 second difference in clocks, unless you're running your certs really close to the notBefore/notAfter. There's enough broken systems out there that it makes sense to not use certs that don't have at least 24 hours of margin on either side.

jhayward 7y ago

One thing that this article evokes is the 'I'm wrong and my belief is deeply held' aspect which technology people occasionally fall in to. Looking at the comments, with incorrect beliefs expressed as dicta ranging from just plain wrong, to incompletely specified, to ordinary confusion is giving my tech-PTSD a workout. 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.

AgentME 7y ago

Here's a falsehood I've seen a bunch of times: the idea that Unix timestamps need to be converted to your local timezone. Unix timestamps are the number of seconds since a specific date in a specific timezone (UTC)! If a user gives you a Unix timestamp and you know they're in the PDT timezone, you should not add or subtract 7 hours of seconds to "convert" the timestamp to UTC! It already is. Similarly, if your client receives a Unix timestamp from your server, you shouldn't modify the Unix timestamp to "convert" it to your user's local timezone. Unix timestamps are always UTC. Your platform's date handling APIs should already offer a way to display a Unix timestamp in the user's timezone or an arbitrary one, and maybe even have a class that represents a Unix timestamp paired up with a specific timezone. At no point should you be doing arithmetic on the Unix timestamp portion to convert it between timezones.

Florin_Andrei 7y ago
> Here's a falsehood I've seen a bunch of times: the idea that Unix timestamps need to be converted to your local timezone. That's less of a "falsehood", more of a complete misunderstanding of what Unix time is.
- rhizome 7y ago
  Yep, a faulty belief is not the same as ignorance.
- AgentME 7y ago
  I think it's a common misunderstanding worth bringing up here that probably affects more people than the falsehoods listed in the article. On roughly 3 out of the 4 times I've had a coworker run into a timezone issue (different person each time), their first impulse was to do something like what I described. (I stopped them early most of the times, so maybe they would have figured out it was the wrong way to go about it.) 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.
7y ago

abtinf 7y ago

Perhaps a stupid question: Why isn't there a time standard that is monotonic and defined simply in terms of seconds, without attempting to match the movement of the earth (no leap seconds, no negative seconds, no daylight savings, no complicated calendar politics)? 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.

msla 7y ago
TAI is what you want.
deleted 7y ago
[deleted]
spydum 7y ago
I can’t WAIT until we have to deal with time dilation problems on networks and certificates.
brlewis 7y ago
Not a stupid question...it's the central question here. 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?

alanfranz 7y ago

So, if I adopt smearing for my NTP, everything works fine.

bradknowles 7y ago
Except then, a second isn't actually a second.
- lodi 7y ago
  But that's always true anyway because of clock drift, skew, etc. Otherwise we wouldn't need NTP in the first place.
- paulddraper 7y ago
  But it pretty much is. Einstein showed us seconds aren't seconds anyway, unless you happened to have the same inertial frame.

legohead 7y ago

I was aware of leap seconds after working for an online auction website. How to deal with all the auctions that may be ending right at or before the leap second? 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.

netmonk 7y ago
Well, well i was working in a major bank, in HFT dpt. We had team all over the world. Our cisco switch were not able to deal correctly with leap second, so basically we had to switch them off just before the leap second, and switch them back on, right after. 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.

martovmarkov 7y ago

Can this cause another "millenium bug" chaos again?

tinix 7y ago

time is hard: https://gordol.github.io/date_time_manipulation.html https://gordol.github.io/date_time_manipulation.html

netmonk 7y ago

for those interested in this kind of topics, i cannot recommand more than suscribe to the timenuts mailing list : http://leapsecond.com/time-nuts.htm http://leapsecond.com/time-nuts.htm

revicon 7y ago

Unix time assumes that each day is exactly 86,400 seconds long (60 × 60 × 24 = 86,400), leap seconds be damned I don't think I understand this claim. Unix time has no concept of a "day". Leap seconds increment UTC time, but doesn't add anything to the number of seconds that have elapsed since unix epoc.

nemetroid 7y ago
That's one of the falsehoods. Unix time is not equal to the number of elapsed seconds since the epoch, it is equal to N x 86400 + s, where N is the number of days that have elapsed since the epoch, and s is the number of seconds that have elapsed since midnight.

alpb 7y ago

There are much longer lists about this, like: https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b... Here are 20 more links: https://github.com/kdeldycke/awesome-falsehood#dates-and-time https://github.com/kdeldycke/awesome-falsehood#dates-and-tim...

anilakar 7y ago

Another falsehood, altough it goes against the POSIX standard: the epoch is midnight in UTC. There is at least one obscure Unix-like OS (can't remember the name) where the epoch is 1970-01-01 in local timezone

acqq 7y ago

The article is wrong or misleading. 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: https://developers.google.com/time/smear https://developers.google.com/time/smear 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.

FabHK 7y ago
Agree. In other words, computers should use UT1 (where one day is a rotation of the earth, and 86400 seconds; and consequently a second is not a SI second).
- acqq 7y ago

joeleisner 7y ago

Never knew about this... interesting article!

PureParadigm 7y ago

Leap seconds definitely add way more complexity/uncertainty when dealing with timestamps in the future. I once made a program that would output the amount of time remaining until some time in the future (with the future time represented as a Unix timestamp). I realized that it is simply not possible to report the number of seconds until an event >6 months in the future because we simply don't know if there might be a leap second or not between now and the time in the future. Perhaps the best approach for users would be to smear any leap seconds that are announced so it never has a hard jump, but it's still not ideal because if you really want to count down to the future time you simply can't.

dmh2000 7y ago

just an anecdote about UTC vs GPS time. GPS time doesn't have leap seconds. 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.

JdeBP 7y ago

A falsehood that Alex Chan believes about UNIX: 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. * https://unix.stackexchange.com/a/327403/5132 https://unix.stackexchange.com/a/327403/5132 * https://unix.stackexchange.com/a/334029/5132 https://unix.stackexchange.com/a/334029/5132 * https://unix.stackexchange.com/a/294715/5132 https://unix.stackexchange.com/a/294715/5132

Kenji 7y ago

> If I wait exactly one second, Unix time advances by exactly one second, unless a leap second has been removed. What complete and utter bogus. Just because some moron in the IERS has defined that my day has more or less seconds doesn't mean time stands still for me. If I wait 1 second in UNIX time, one second passes. As in: If I am travelling at 1 meter per second, and I wait one second in UNIX time, I travelled one meter. Maybe UTC didn't advance but time in the real, actual world advanced. The ground truth is UNIX time which advances monotonically and linearly. UTC is a political garbage mess plopped on top of actual time. So, on the graph you've got it the wrong way around: The x-axis should be UNIX time, the y-axis should be UTC time.

diminoten 7y ago

> So far, there’s never been a leap second removed in practice (and the Earth’s slowing rotation means it’s unlikely) Oh, okay. Thanks!

chithanh 7y ago
Earthquakes and other geological events can speed up rotation though, but so far never enough to remove a leap second.

tqwhite 7y ago

Unix time is the humber of seconds since 1970. Seconds are a physical thing. Unix time references the number of "cycles of the radiation produced by the transition between two levels of the cesium 133 atom" UTC measures time. This article is silly.

masklinn 7y ago
> Unix time is the humber of seconds since 1970. It's not, and it has never been. The original unix time was "the time since 00:00:00, 1 January 1971, measured in sixtieths of a second", this got modified multiple times until it settled upon the number of UTC seconds since 1970-01-01T00:00:00Z, meaning it's non-monotonic, non-continuous, and not based on "physical" seconds.

bcaa7f3a8bbc 7y ago

The original purpose of Unix time was decoupling local time representation and internal timekeeping of the system. Unix time could be the "One True Time" of the system, it always increases monotonically. When you need local time, all the tricky and nasty details, including DST, mandated calendar changes, etc, are processed by the tzinfo system library/database. If the calendar has changed, at least in principle one does not and should not have to update the system clock or most unrelated applications, simply update tzinfo and you're done. 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?

nitwit005 7y ago
> Unfortunately, Unix time did not considered the effects of leap second The change to UTC to include leap seconds was in 1972, which was after unix time came into existence.
- bcaa7f3a8bbc 7y ago
  It has nothing to do with my argument, there could be awareness, to the extents that Unix architects had seen it in the news, but still, it was not considered. I don't believe support of leap second was built into Unix and honored properly until 1990s, when NTP became prevalent. 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.
wodenokoto 7y ago

averros 7y ago

Basically, everyone who has a clue about time standards uses TAI for internal representation in non-relativisitic applications. 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.

averros 7y ago
...oh, and there's also the issue of time domains and time sources having different spectral shapes of their noise.

osrec 7y ago

So when we convert Unix time to Y-m-d format, are those conversion algorithms aware of the leap seconds? Is it hard coded in there somewhere?

dkbrk 7y ago

Perhaps I don't fully understand the reasoning that went into these things when they were decided, but I think the following would be more sane: - 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.

max76 7y ago

I think we should have a scientific definition of time -- something that is highly static and precise (such as the time it takes for an atom to vibrant a number of times, or the time it takes light in a vacuum to travel a certain distance) and a cultural definition of time that is more loose than UTC (There is always the same number of seconds in a day, but maybe some days have shorter seconds than other days). Cultural time is fine and dandy for human level stuff. Keep that simple. Scientific time for business, engineering and scientific stuff.

brianpan 7y ago
Time might not be too hard to define (relativistic effects aside), but the problem is days and years. The reason for inserting and removing seconds is because the rotation of the earth is NOT static and precise. It changes so seconds are added and removed to keep the day from drifting. https://en.wikipedia.org/wiki/Day_length_fluctuations https://en.wikipedia.org/wiki/Day_length_fluctuations
masklinn 7y ago
> Cultural time is fine and dandy for human level stuff. Keep that simple. Scientific time for business, engineering 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).

xucheng 7y ago

To see the current value for different time standards (e.g. UTC, GPS, TAI): http://leapsecond.com/java/gpsclock.htm http://leapsecond.com/java/gpsclock.htm

gauravphoenix 7y ago

a fun command to run: cal 9 1752

dancek 7y ago

I've been thinking about datetime APIs and how most of them become extremely tedious when you have to account for daylight saving, countries changing time zones et cetera. I was actually planning to write my own implementation for $language using unix timestamps as internal representation and requiring a timezone whenever parsing or printing. But then I considered leap seconds. 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.

masklinn 7y ago
> I was actually planning to write my own implementation for $language using unix timestamps as internal representation and requiring a timezone whenever parsing or printing 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).
- dancek 7y ago
  Yes. Almost everything is subtly broken, and I realized my attempt would be broken too. Didn't feel like a fun hobby project once I realized that.

kstenerud 7y ago

This is why I use smalltime when storing time values. https://github.com/kstenerud/smalltime https://github.com/kstenerud/smalltime

unhammer 7y ago

http://yourcalendricalfallacyis.com/ http://yourcalendricalfallacyis.com/

time_travlr 7y ago

Why does Unix time first travel forward one second, then go backwards one second, versus "pausing" (flat line on the graph) one second? Both have their pros and con; if the graph accurately depicts how Unix time is implemented, why was this decision made versus the other?

bloak 7y ago

Having spent some time studying time keeping in computers, I've come to the conclusion that nothing needs to be changed. In particular, UTC is exactly what it should be and should be left as it is. However, there are some things that need to be added: * 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.

hedora 7y ago

I’m not convinced this article is correct. Posix defers to ISO C where they differ: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf 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/ 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.

rlucas 7y ago

My Unix time question is, when I do “sudo date <DDMMhhmmyyyy>” and then get a sudo password prompt, is the time supposed to take effect before or after the sudo is authenticated? 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?

bheiskell 7y ago
After, because sudo won’t run any command until it authorizes that you’re allowed to run the command.