12 ms·

Seconds Since the Epoch

298 points by zdw 2y ago

silisili 2y ago
> People, myself included, like to say that POSIX time, also known as Unix time, is the number of seconds since the Unix epoch, which was 1970-01-01 at 00:00:00. > This is not true. Or rather, it isn’t true in the sense most people think. I find that assertion odd, because it works exactly as I did assume. Though, to be fair, I'm not thinking in the scientific notion that the author may. If we think of a second as a tick of some amount of time, it makes sense to just count up once each tick. That scientists inject a second here or there wouldn't interfere with such logic. All of that said, the leap second is going away anyways, so hopefully whatever replaces it is less troublesome.
- apgwoz 2y ago
  The leap second in Unix time is supposed to wait a second and pretend it never happened. I can see why a longer second could be trouble, but also… if you knew it was coming you could make every nanosecond last 2 and lessen the impact as time would always be monotonic?
  - ziml77 2y ago
    That's how Google documents their handling of it: https://developers.google.com/time/smear https://developers.google.com/time/smear
- lmm 2y ago
  > If we think of a second as a tick of some amount of time, it makes sense to just count up once each tick. It would, but Unix timestamps don't. It works exactly not how you assume.
  - silisili 2y ago
    Explain? The article is claiming POSIX ignores injected leap seconds.
    - ec109685 2y ago
      POSIX doesn’t ignore leap seconds. Occasionally systems repeat a second, so time doesn’t drift beyond a second from when leap seconds were invented: https://en.wikipedia.org/wiki/Leap_second https://en.wikipedia.org/wiki/Leap_second
      - silisili 2y ago
        After reading this article no less than 3 times, and the comments in this thread, I'm beyond lost. So maybe the author was right. Because different people are claiming different things.
        zokier 2y ago
        The Unix time article has concrete example with tables which should clarify the matter. https://en.wikipedia.org/wiki/Unix_time#Leap_seconds https://en.wikipedia.org/wiki/Unix_time#Leap_seconds In that example, Unix time goes from 915148799 -> 915148800 -> 915148800 -> 915148801. Note how the timestamp gets repeated during leap second.
    - lmm 2y ago
      The article is needlessly unclear, but the specification given in the second blockquote is the one that is actually applied, and a simpler way of explaining it is: POSIX time() returns 86400 * [the number of UTC midnights since 1970-01-01T00:00:00] + [the number of seconds since the last UTC midnight].
sevensor 2y ago
What I don’t understand is why we would ever assume two clocks in two different places could be compared in a non approximate way. Your clock, your observations of the world state, are always situated in a local context. In the best of all possible cases, the reasons why your clock and time reports from other clocks differ are well understood.
- pavel_lishin 2y ago
  camera cuts across to Newton, seething on his side of the desk, his knuckles white as the table visibly starts to crack under his grip
- ses1984 2y ago
  I think something like the small angle approximation applies. There are plenty of applications where you can assume clocks are basically in the same frame of reference because relativistic effects are orders of magnitude smaller than your uncertainty.
- christina97 2y ago
  The approximation error is so small that you can often ignore it. Hence the concept of exact time. Eg in most computing contexts, you can synchronize clocks close enough to ignore a few nanos difference.
  - Asraelite 2y ago
    How? Unless you have an atomic clock nearby, they will very quickly drift apart by many nanoseconds again. It's also impossible to synchronize to that level of precision across a network.
    - AlotOfReading 2y ago
      It's not only possible, you can demonstrate it on your phone. Check the GPS error on your device in a clear area. 1 ft of spatial error is roughly 1ns timing error on the signal (assuming other error sources are zero). Alternatively, you can just look at the published clock errors: http://navigationservices.agi.com/GNSSWeb/PAFPSFViewer.aspx http://navigationservices.agi.com/GNSSWeb/PAFPSFViewer.aspx All the satellites in all of the GNSS constellations are synchronized to each other and every device tracking them to within a few tens of nanoseconds. Yes, atomic clocks are involved, but none of them are corrected locally and they're running at a significantly different rate than "true" time here on earth.
move-on-by 2y ago
Without fail, if I read about time keeping, I learn something new. I had always thought unix time as the most simple way to track time (as long as you consider rollovers). I knew of leap seconds, but somehow didn’t think they applied here. Clearly I hadn’t thought about it enough. Good post. I also read the link for “UTC, GPS, LORAN and TAI”. It’s an interesting contrast that GPS time does not account for leap seconds.
- foobar1962 2y ago
  Saying that something happened x-number of seconds (or minutes, hours, days or weeks) ago (or in the future) is simple: it’s giving that point in time a calendar date that’s tricky.
  - wodenokoto 2y ago
    Simple as long as your precision is at milliseconds and you don’t account for space travel. We can measure the difference in speed of time in a valley and a mountain (“just” take an atomic clock up a mountain and wait for a bit, bring it back to your lab where the other atomic clock is now out of sync)
  - GolDDranks 2y ago
    But because of the UNIX time stamp "re-synchronization" to the current calendar dates, you can't use UNIX time stamps to do those "delta seconds" calculations if you care about _actual_ amount of seconds since something happened.
  - miki123211 2y ago
    > Saying that something happened x-number of [...]days or weeks) ago in the future) is simple It's not, actually. Does 2 days and 1 hour ago mean 48, 49 or 50 hours, if there was a daylight saving jump in the meantime? If it's 3PM and something is due to happen in 3 days and 2 hours, the user is going to assume and prepare for 5PM, but what if there's a daylight saving jump in the meantime? What happens to "in 3 days and 2 hours" if there's a leap second happening tomorrow that some systems know about and some don't? You rarely want to be thinking in terms of deltas when considering future events. If there is an event that you want to happen on jan 1, 2030 at 6 PM CET, there is no way to express that as a number of seconds between now and then, because you don't know whether the US government abolishes DST between now and 2030 or not. To reiterate this point, there is no way to make an accurate, constantly decreasing countdown of seconds to 6PM CET on jan 1, 2030, because nobody actually knows when that moment is going to happen yet.
computator 2y ago
> POSIX time, also known as Unix time, is the number of seconds since the Unix epoch, which was 1970-01-01 at 00:00:00. … I think there should be a concise explanation of the problem. I don’t think that the definition that software engineers believe is wrong or misleading at all. It really is the number of seconds that have passed since Unix’s “beginning of time”. But to address the problem the article brings up, here’s my attempt at a concise definition: POSIX time, also known as Unix time, is the number of seconds since the Unix epoch, which was 1970-01-01 at 00:00:00, and does not include leap seconds that have been added periodically since the 1970s.
- juped 2y ago
  It really is the number of seconds that have passed since Unix's "beginning of time", minus twenty-nine. Some UTC days have 86401 seconds, Unix assumes they had 86400. It's wrong and misleading in precisely the way you (and other commenters here) were wrong and misled, so it seems like that's a fair characterization.
- jodrellblank 2y ago
  Atomic clocks measure time passing. Seconds are a fraction of a day which is Earth rotating, and count 86400 seconds and then roll over to the next day, but Earth's rotating speed changes so how much "time passing" is in 86400 seconds varies a little. Clocks based on Earth rotating get out of sync with atomic clocks. Leap seconds go into day-rotation clocks so their date matches the atomic clock measure of how much time has passed - they are time which has actually passed and ordinary time has not accounted for; so it's inconsistant for you to say "Unix time really is the number of seconds that have passed" and "does not include leap seconds" because those leap seconds are time that has passed.
- Calamityjanitor 2y ago
  I think you're describing the exact confusion that developers have. Unix time doesn't include leap seconds, but they are real seconds that happened. Consider a system that counts days since 1970, but ignores leap years so doesn't count Feb 29. Those 29ths were actual days, just recorded strangely in the calendar. A system that ignores them is going to give you an inaccurate number of days since 1970.
calrain 2y ago
When storing dates in a database I always store them in Unix Epoch time and I don't record the timezone information on the date field (it is stored separately if there was a requirement to know the timezone). Should we instead be storing time stamps in TAI format, and then use functions to convert time to UTC as required, ensuring that any adjustments for planetary tweaks can be performed as required? I know that timezones are a field of landmines, but again, that is a human construct where timezone boundaries are adjusted over time. It seems we need to anchor on absolute time, and then render that out to whatever local time format we need, when required.
- hx8 2y ago
  Maybe, it really depends on what your systems are storing. Most systems really won't care if you are one second off every few years. For some calculations being a second off is a big deal. I think you should tread carefully when adopting any format that isn't the most popular and have valid reasons for deviating from the norm. The simple act of being different can be expensive.
- semiquaver 2y ago
  > and I don't record the timezone information on the date field Very few databases actually make it possible to preserve timezone in a timestamp column. Typically the db either has no concept of time zone for stored timestamps (e.g. SQL server) or has “time zone aware” timestamp column types where the input is converted to UTC and the original zone discarded (MySQL, Postgres) Oracle is the only DB I’m aware of that can actually round-trip nonlocal zones in its “with time zone” type.
  - mulmen 2y ago
    As always the Postgres docs give an excellent explanation of why this is the case: https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-TIMEZONES https://www.postgresql.org/docs/current/datatype-datetime.ht...
    - Scarblac 2y ago
SerCe 2y ago
Working with time is full of pitfalls, especially around clock monotonicity and clock synchronisation. I wrote an article about some of those pitfalls some time ago [1]. Then, you add time zones to it, and you get a real minefield. [1]: https://serce.me/posts/16-05-2019-the-matter-of-time https://serce.me/posts/16-05-2019-the-matter-of-time
- mmooss 2y ago
  You are a developer who works with time and you named your file, "16-05-2019-the-matter-of-time"? :)
  - eru 2y ago
    What's wrong with that?
    - lysium 2y ago
      That’s not a standard format. ISO format is yyyy-mm—dd. Also, sorts nicely by time if you sort alphabetically.
      - eru 2y ago
        Yes, I know. But for your personal file names, you can pick whatever you feel like.
    - BrandoElFollito 2y ago
      They wrote it on the 16th of May, or the 5th of Bdrfln, we will never know.
      - eru 2y ago
        Perhaps it's just named for that date, and not written then? In any case, dates only have to make sense in the context they are used. Eg we don't know from just the string of numbers whether it's Gregorian, Julian, or Buddhist or Japanese etc calendar.
quotemstr 2y ago
So what if leap seconds make the epoch 29 seconds longer-ago than date +%s would suggest? It matters a lot less than the fact that we all agree on some number N to represent the current time. That we have -29 fictional seconds doesn't affect the real world in any way. What are you going to do, run missile targeting routines on targets 30 years ago? I mean, I'm as much for abolish leap seconds as anyone, but I don't think it's useful --- even if it's pedantically correct --- to highlight the time discrepancy.
- chrchr 2y ago
  It matters for some things. Without those fictional leap seconds, the sun would be 29 seconds out of position at local noon, for instance.
  - School-Cotton 2y ago
    That does not matter at all to anyone.
    - porridgeraisin 2y ago
      Yeah. "Exact time" people are a bit like "entropy" people in cryptography. Constantly arguing about the perfect random number when nobody cares.
    - growse 2y ago
      Did you ask everyone? It most certainly matters to a lot of people. It sounds like you've never met those people.
      - zokier 2y ago
        For practically everyone the local civil time is off from local solar time more than 30 seconds, because very few people live at the exact longitude that corresponds to their time zone. And then you got DST which throws the local time even more off. This is ignoring the fact that due equation of time, solar noon naturally shifts around tens of minutes over the course of the year. To drive the point, for example local mean solar time at Buckingham palace is already more than 30 seconds off from Greenwich time.
christina97 2y ago
Lot of people seem to miss the point of the article. Suppose you had a clock that counted seconds (in the way we understand seconds, moving forward one unit per second). If you looked at it in a few days at midnight UTC on NYE (according to any clock), it would not be a multiple of 86400 (number of seconds per day). It would be off by some 29 seconds due to leap seconds. In that way, Unix time is not seconds since the epoch.
- School-Cotton 2y ago
  You have it backwards. If you look at it at midnight UTC (on any day, not just NYE) it WOULD be an exact multiple of 86400. (Try it and see.) Because of leap seconds, this is wrong. Midnight UTC tonight is in fact NOT a multiple of 86,400 real, physical seconds since midnight UTC on 1970-01-01.
  - jacobgkau 2y ago
    He didn't have it backwards, he was saying the same thing as you. He said, "suppose you had a clock that counted seconds," then described how it would work (it would be a non-multiple) if that was the case, which it isn't. You ignored that his description of the behavior was part of a hypothetical and not meant to describe how it actually behaves.
    - School-Cotton 2y ago
      You’re absolutely right — not sure how I misinterpreted that so badly.
    - christina97 2y ago
      Thanks but I’m a “she” :)
jonnycomputer 2y ago
I think this article ruined my Christmas. Is nothing sacred? seconds should be seconds since epoch. Why should I care if it drifts off solar day? Let seconds-since-epoch to date representation converters be responsible for making the correction. What am I missing?
- christina97 2y ago
  The way it is is really how we all want it. 86400 seconds = 1 day. And we operate under the assumption that midnight UTC is always a multiple of 86400. We don’t want every piece of software to start hardcoding leap second introductions and handling smears and requiring a way to update it within a month when a new leap second is introduced. You never worried or thought about it before, and you don’t need to! It’s done in the right way.
  - turminal 2y ago
    But most software that would need to care about that already needs to care about timezones, and those already need to be regularly updated, sometimes with not much more than a month's notice.
    - dmoy 2y ago
      I will never forgive Egypt for breaking my shit with a 3 day notice (what was it like 10 years ago?). Thankfully for me it was just a bunch of non-production-facing stuff.
      - kragen 2y ago
        Was this Morsy's government or Sisi's? If it's Morsy's government you're holding a grudge against, I have some good news for you. (Presumably you're not holding that grudge against random taxi drivers and housewives in Alexandria.)
        dmoy 2y ago
maxbond 2y ago
> ((tm_year - 69) / 4) * 86400 Seems like there's another corner cut here, where the behavior of leap years at the end of a century (where they're skipped if a year is divisible by 100 unless it's divisible by 400) is not accounted for. I suppose using Unix time for dates in the far future isn't a good idea. I guess I'll file that away. (For the curious, the way this seems to work is that it's calibrated to start ticking up in 1973 and every 4 years thereafter. This is integer math, so fractional values are rounded off. 1972 was a leap year. From March 1st to December 31st 1972, the leap day was accounted for in `tm_yday`. Thereafter it was accounted for in this expression.)
- growse 2y ago
  > I suppose using Unix time for dates in the far future isn't a good idea. I guess I'll file that away. Not just Unix time, converting future local time to UTC and storing that is also fraught with risk, as there's no guarantee that the conversion you apply today will be the same as the one that needs to be applied in the future. Often (for future dates), the right thing to do is to store the thing you were provided (e.g. a local timestamp + the asserted local timezone) and then convert when you need to. (Past dates have fewer problems converting to UTC, because we don't tend to retroactively change the meaning of timezones).
- jwilk 2y ago
  > the behavior of leap years at the end of a century (where they're skipped if a year is divisible by 100 unless it's divisible by 400) is not accounted for. The article cites the original edition of POSIX from 1988. The bug in question was fixed in the 2001 edition: https://pubs.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html#tag_04_14 https://pubs.opengroup.org/onlinepubs/007904975/basedefs/xbd...
schneehertz 2y ago
This means that some time points cannot be represented by POSIX timestamps, and some POSIX timestamps do not correspond to any real time
- marcosdumay 2y ago
  Well, at least there isn't any POSIX timestamp that correspond to more than one real time point. So, it's better than the one representation people use for everything.
  - brianpan 2y ago
    Not yet.
- growse 2y ago
  This has always been true. Pre 1970 is not defined in Unix time.
  - usrnm 2y ago
    Why? time_t is signed
    - growse 2y ago
      From IEE 1003.1 (and TFA): > If year < 1970 or the value is negative, the relationship is undefined.
    - layer8 2y ago
      In addition to being formally undefined (see sibling comment), APIs sometimes use negative time_t values to indicate error conditions and the like.
    - 8n4vidtmkvmk 2y ago
      Probably because the Gregorian calendar didn't always exist. How do you map an int to a calendar that doesn't exist?
tw1984 2y ago
there is literally no easy and safe way to actually handle leap seconds. what happens when they need to remove one second? even for the easier case of inserted leap second, you can smear it, but what happens if there are multiple systems each smearing it at different rates? I'd strongly argue that you pretty much have to reboot all your time critical and mission critical systems during the leap second to be safe. the issue is so wide spread and complicated that they decided to stop introducing extra leap seconds so people can come up with something better in the coming decades - probably way later than the arrival of AGI.
vendiddy 2y ago
Maybe a naive question but why wasn't the timestamp designed as seconds since the epoch with zero adjustments? Everything would be derived from that. I suppose it would make some math more complex but overall it feels simpler.
- growse 2y ago
  With hindsight, we'd do lots of things differently :) I guess they just didn't foresee the problem, or misjudged the impact. I can imagine it being very "let's kick that problem down the road and just do a simple thing for now" approach.
  - wat10000 2y ago
    UNIX systems at the time probably didn’t care about accuracy to the second being maintained over rare leap second adjustments. Random example, the wonderful RealTime1987A project (https://bmonreal.github.io/RealTime1987A/ https://bmonreal.github.io/RealTime1987A/) talks about detecting neutrinos from the supernova, and what information can be inferred from the timing of the detections. A major source of that data is the Super Kamiokande project. The data was recorded to tape by a PDP-11, timestamped by its local clock. That clock was periodically synced with UTC with a sophisticated high-tech procedure that consisted of an operator making a phone call to some time service, then typing the time into the computer. As such, the timestamps recorded by this instrument have error bars of something like +/- one minute. If that’s the sort of world you’re in, trying to account for leap seconds probably seems like a complete waste of effort and precious computer memory.
- fragmede 2y ago
  Arguably it's worse if 00:33 on 2024.12.26 has to get run through another function to get the true value of 2024.12.25 T 23:59. The problem is leap seconds. Software just wasn't designed to handle 86401 seconds in a day, and caused incidents at Google, Cloudflare, Quantus, and others. Worried that resolving all possible bugs related to days with 86401 seconds in them was going to be impossible to get right, Google decided to smear that leap second so that the last "second" isn't. And if you've not seen it, there's the falsehoods programmers believe about time article.
zaran 2y ago
I wonder if the increasing number of computers in orbit will mean even more strange relativistic timekeeping stuff will become a concern for normal developers - will we have to add leap seconds to individual machines? Back of the envelope says ~100 years in low earth orbit will cause a difference of 1 second
- gavinsyancey 2y ago
  Most of those probably don't/won't have clocks that are accurate enough to measure 1 second every hundred years; typical quartz oscillators drift about one second every few weeks.
- Rastonbury 2y ago
  For GPS at least it is accounted for 38 microseconds per day, they have atomic clocks accurate to like 0.4 milliseconds over 100 years. The frequencies they measure at are different from earth and are constantly synchronised.
paradite 2y ago
Typically you don't need to worry about leap seconds on server because AWS or GCP will help you handle it. You just need to read the docs to understand their behavior. Some will smooth it out for you, some will jump for you. It would be a problem if you have 3rd party integrations and you rely on their timestamp.
mgaunard 2y ago
The timestamps given in the article seem completely wrong? Also, where would 29 even come from? The offset between UTC and TAI is 37 seconds.
- possiblywrong 2y ago
  You are correct. The first example time in the article, "2024-12-25 at 18:54:53 UTC", corresponds to POSIX timestamp 1735152893, not 1735152686. And there have been 27 leap seconds since the 1970 epoch, not 29.
- Retr0id 2y ago
  I'm also not sure where 29 came from, but the expected offset here is 27 - there have been 27 UTC leap seconds since the unix epoch.
DrBazza 2y ago
There's a certain exchange out there that I wrote some code for recently, that runs on top of VAX, or rather OpenVMS, and that has an epoch of November 17, 1858, the first time I've seen a mention of a non-unix epoch in my career. Fortunately, it is abstracted to be the unix epoch in the code I was using.
- pavlov 2y ago
  Apparently the 1858 epoch comes from an astronomy standard calendar called the Julian Day, where day zero was in 4713 BC: https://www.slac.stanford.edu/~rkj/crazytime.txt https://www.slac.stanford.edu/~rkj/crazytime.txt To make these dates fit in computer memory in the 1950s, they offset the calendar by 2.4 million days, placing day zero on November 17, 1858.
  - deleted 2y ago
    [deleted]
  - hanche 2y ago
    It’s called the modified Julian day (MJD). And the offset is 2,400,000.5 days. In the Julian day way of counting, each day ended at noon, so that all astronomical observations done in one night would be the same Julian day, at least in Europe. MJD moved the epoch back to midnight. https://en.wikipedia.org/wiki/Julian_day https://en.wikipedia.org/wiki/Julian_day
- spiffytech 2y ago
  There's an old Microsoft tale related to the conflict between Excel's epoch of Jan 1 1900 vs Basic's Dec 31 1899: https://www.joelonsoftware.com/2006/06/16/my-first-billg-review/ https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
- evmar 2y ago
  Another common computing system to be aware of: the Windows epoch is 1-Jan-1601.
- NoInkling 2y ago
  PostgreSQL internally uses a 2000-01-01 epoch for storing timestamps.
nubinetwork 2y ago
Isn't this the point to the tz files shipped on every linux system? If the crappy online converters only do the basic math formula, of course it's going to be off a little...
xpe 2y ago
Is there a synchronized and monotonically increasing measure of time to be found?
- kevindamm 2y ago
  Not really. GPS time comes close (at least, it avoids leap seconds and DST) but you still have technical issues like clock drift.
colanderman 2y ago
Note also that the modern "UTC epoch" is January 1, 1972. Before this date, UTC used a different second than TAI: [1] > As an intermediate step at the end of 1971, there was a final irregular jump of exactly 0.107758 TAI seconds, making the total of all the small time steps and frequency shifts in UTC or TAI during 1958–1971 exactly ten seconds, so that 1 January 1972 00:00:00 UTC was 1 January 1972 00:00:10 TAI exactly, and a whole number of seconds thereafter. At the same time, the tick rate of UTC was changed to exactly match TAI. UTC also started to track UT1 rather than UT2. So Unix times in the years 1970 and 1971 do not actually match UTC times from that period. [2] [1] https://en.wikipedia.org/wiki/Coordinated_Universal_Time#History https://en.wikipedia.org/wiki/Coordinated_Universal_Time#His... [2] https://en.wikipedia.org/wiki/Unix_time#UTC_basis https://en.wikipedia.org/wiki/Unix_time#UTC_basis
- weinzierl 2y ago
  A funny consequence of this is that there are people alive today that do not know (and never will know) their exact age in seconds[1]. This is true even if we assume the time on the birth certificate was a time precise down to the second. It is because what was considered the length of a second during part of their life varied significantly compared to what we (usually) consider a second now. [1] Second as in 9192631770/s being the the unperturbed ground-state hyperfine transition frequency of the caesium 133 atom
  - benlivengood 2y ago
    [2] in a particular gravity well.
  - deleted 2y ago
    [deleted]
cbarrick 2y ago
> There’s an ongoing effort to end leap seconds, hopefully by 2035. I don't really like this plan. The entire point of UTC is to be some integer number of seconds away from TAI to approximate mean solar time (MST). If we no longer want to track MST, then we should just switch to TAI. Having UTC drift away from MST leaves it in a bastardized state where it still has historical leap seconds that need to be accounted for, but those leap seconds no longer serve any purpose.
- phicoh 2y ago
  The is no such thing as TAI. TAI is what you get if you start with UTC and then subtract the number of leap seconds you care about. TAI is not maintained as some sort of separate standard quantity. In most (all?) countries, civil time is based on UTC. Nobody is going to set all clocks in the world backwards by about half a minute because it is somewhat more pure. GPS time also has an offset compared to TAI. Nobody care a bout that. Just like nobody really cares about the Unix epoch. As long as results are consistent.
  - gerdesj 2y ago
    The only think we can be certain of is that the Summer Solstice occurs when the mid summer sun shines through a trillithon at Stonehenge and strikes a certain point. From there we can work outwards. The logical thing to do is to precisely model Stonehenge to the last micron in space. That will take a bit of work involving the various sea levels and so on. So on will include the thermal expansion of granite and the traffic density on the A303 and whether the Solstice is a bank holiday. Oh bollocks ... mass. That standard kilo thing - is it sorted out yet? Those cars and lorries are going to need constant observation - we'll need a sort of dynamic weigh bridge that works at 60mph. If we slap it in the road just after (going west) the speed cameras should keep the measurements within parameters. If we apply now, we should be able to get Highways to change the middle of the road markings from double dashed to a double solid line and then we can simplify a few variables. ... more daft stuff ... Right, we've got this. We now have a standard place and point in time to define place and time from. No we don't and we never will. There is no absolute when it comes to time, place or mass. What we do have is requirements for standards and a point to measure from. Those points to measure from have differing requirements, depending on who who you are and what you are doing. I suggest we treat time as we do sea level, with a few special versions that people can use without having to worry about silliness. Provided I can work out when to plant my wheat crop and read log files with sub micro second precision for correlation, I'll be happy. My launches to the moon will need a little more funkiness ...
ZeroCool2u 2y ago
More often than I care to admit, I yearn for another of Aphers programming interview short stories. Some of my favorite prose and incredibly in depth programming.
ck2 2y ago
I would not be on a plane or maybe even an elevator mid-January 2038 if it can do this to cloudflare, imagine everything left on legacy signed 32bit integers https://blog.cloudflare.com/how-and-why-the-leap-second-affected-cloudflare-dns/ https://blog.cloudflare.com/how-and-why-the-leap-second-affe...
ascorbic 2y ago
I just finished reading "A Deepness in the Sky" a 2000 SF book by Vernor Vinge. It's a great book with an unexpected reference to seconds since the epoch. >Take the Traders' method of timekeeping. The frame corrections were incredibly complex - and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth's moon. But if you looked at it still more closely ... the starting instant was actually about fifteen million seconds later, the 0-second of one of Humankind's first computer operating systems.
- jvanderbot 2y ago
  That is one of my favorite books of all time. The use of subtle software references is really great. I recommend Bobiverse series for anyone who wants more "computer science in space" or permutation city for anyone who wants more "exploration of humans + simulations and computers"
  - nnf 2y ago
    I’ll second the Bobiverse series, one of my favorites. Its descriptions of new technologies is at just the right level and depth, I think, and it’s subtly hilarious.
    - noja 2y ago
      The audio books are narrated brilliantly too. Stange fact: bobiverse has no dedicated Wikipedia page.
      - MobileVet 2y ago
        Ray Porter, the narrator, is quite the talent. He does a brilliant job with ‘Project: Hail Mary’ as well which is the second book from the author of ‘The Martian.’ It has quite a bit more science and humor than The Martian and is one of my favorites.
    - MobileVet 2y ago
prmph 2y ago
The more I learn about the computation of time, the more unbelievably complex getting it right seems. I thought I was pretty sophisticated in in my view of time handling, but just in the last couple of months there have been a series of posts on HN that have opened my eyes even more to how leaky this abstraction of computer time is. Pretty soon we'll have to defer to deep experts and fundamental libraries to do anything at all with time in our applications, a la security and cryptography.
sarusso 2y ago
I remember hearing at a conference about 10 years ago that Google does not make use of leap seconds. Instead, they spread them across regular seconds (they modified their NTP servers). I quickly searched online and found the original article [1]. [1] https://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html https://googleblog.blogspot.com/2011/09/time-technology-and-...
- jhalstead 2y ago
  Their public NTP doc for the "leap smear" also includes some other leap smear proposals: https://developers.google.com/time/smear https://developers.google.com/time/smear
odyssey7 2y ago
What we’re seeing is again the scientists trying to constrain a humanist system into a scientifically precise framework. It doesn’t really tend to work out. I’m reminded of the time that a bunch of astronomers decided to redefine what a planet is, and yet the cultural notion of Pluto remains strong. Science and culture will rarely move hand-in-glove, so the rule of separation or concerns, to decouple human experience from scientific measurement, applies.
gregfjohnson 2y ago
I've been trying to find discussion of this topic on Hacker News between October 1582 and September 1752, but to no avail. 'cal 9 1752' is .. funny. I guess instead of doing this annoying a-periodic leap second business, they accumulated a bunch of leap seconds owed, and skipped 11 days at one go. Sysadmins at the time were of divided opinion on the matter.
_kst_ 2y ago
Leap seconds should be replaced by large rockets mounted on the equator. Adjust the planet, not the clock.
- _1tem 2y ago
  It'd be not-so-funny if there was a miscalculation and the Earth was slowed down or sped up too much. There's a story about the end of times and the Antichrist (Dajjal) in the Muslim traditions where this sort of thing actually happens. It is said that the "first day of the Antichrist will be like a year, the second day like a month, and third like a week", which many take literally, i.e. a cosmic event which actually slows down the Earth's rotation, eventually reversing course such that the sun rises from the West (the final sign of the end of humanity).
willvarfar 2y ago
The advantage of equal-length days is that know now what some future date represents; whereas if counting leap-seconds too etc you might get a different date computing now compared to future code that knows about any leap seconds between now and then.
srijan4 2y ago
Somewhat related: I really like Erlang's docs about handling time. They have common scenarios laid out and document which APIs to use for them. Like: retrieve system time, measure elapsed time, determine order of events, etc. https://www.erlang.org/doc/apps/erts/time_correction.html#how-to-work-with-the-new-api https://www.erlang.org/doc/apps/erts/time_correction.html#ho...

298 points by zdw 2y ago

> People, myself included, like to say that POSIX time, also known as Unix time, is the number of seconds since the Unix epoch, which was 1970-01-01 at 00:00:00. > This is not true. Or rather, it isn’t true in the sense most people think. I find that assertion odd, because it works exactly as I did assume. Though, to be fair, I'm not thinking in the scientific notion that the author may. If we think of a second as a tick of some amount of time, it makes sense to just count up once each tick. That scientists inject a second here or there wouldn't interfere with such logic. All of that said, the leap second is going away anyways, so hopefully whatever replaces it is less troublesome.

apgwoz 2y ago
The leap second in Unix time is supposed to wait a second and pretend it never happened. I can see why a longer second could be trouble, but also… if you knew it was coming you could make every nanosecond last 2 and lessen the impact as time would always be monotonic?
- ziml77 2y ago
  That's how Google documents their handling of it: https://developers.google.com/time/smear https://developers.google.com/time/smear
lmm 2y ago
> If we think of a second as a tick of some amount of time, it makes sense to just count up once each tick. It would, but Unix timestamps don't. It works exactly not how you assume.
- silisili 2y ago
  Explain? The article is claiming POSIX ignores injected leap seconds.
  - ec109685 2y ago
    POSIX doesn’t ignore leap seconds. Occasionally systems repeat a second, so time doesn’t drift beyond a second from when leap seconds were invented: https://en.wikipedia.org/wiki/Leap_second https://en.wikipedia.org/wiki/Leap_second
    - silisili 2y ago
      After reading this article no less than 3 times, and the comments in this thread, I'm beyond lost. So maybe the author was right. Because different people are claiming different things.
      - zokier 2y ago
        The Unix time article has concrete example with tables which should clarify the matter. https://en.wikipedia.org/wiki/Unix_time#Leap_seconds https://en.wikipedia.org/wiki/Unix_time#Leap_seconds In that example, Unix time goes from 915148799 -> 915148800 -> 915148800 -> 915148801. Note how the timestamp gets repeated during leap second.
  - lmm 2y ago
    The article is needlessly unclear, but the specification given in the second blockquote is the one that is actually applied, and a simpler way of explaining it is: POSIX time() returns 86400 * [the number of UTC midnights since 1970-01-01T00:00:00] + [the number of seconds since the last UTC midnight].

sevensor 2y ago

What I don’t understand is why we would ever assume two clocks in two different places could be compared in a non approximate way. Your clock, your observations of the world state, are always situated in a local context. In the best of all possible cases, the reasons why your clock and time reports from other clocks differ are well understood.

pavel_lishin 2y ago
camera cuts across to Newton, seething on his side of the desk, his knuckles white as the table visibly starts to crack under his grip
ses1984 2y ago
I think something like the small angle approximation applies. There are plenty of applications where you can assume clocks are basically in the same frame of reference because relativistic effects are orders of magnitude smaller than your uncertainty.
christina97 2y ago
The approximation error is so small that you can often ignore it. Hence the concept of exact time. Eg in most computing contexts, you can synchronize clocks close enough to ignore a few nanos difference.
- Asraelite 2y ago
  How? Unless you have an atomic clock nearby, they will very quickly drift apart by many nanoseconds again. It's also impossible to synchronize to that level of precision across a network.
  - AlotOfReading 2y ago
    It's not only possible, you can demonstrate it on your phone. Check the GPS error on your device in a clear area. 1 ft of spatial error is roughly 1ns timing error on the signal (assuming other error sources are zero). Alternatively, you can just look at the published clock errors: http://navigationservices.agi.com/GNSSWeb/PAFPSFViewer.aspx http://navigationservices.agi.com/GNSSWeb/PAFPSFViewer.aspx All the satellites in all of the GNSS constellations are synchronized to each other and every device tracking them to within a few tens of nanoseconds. Yes, atomic clocks are involved, but none of them are corrected locally and they're running at a significantly different rate than "true" time here on earth.

move-on-by 2y ago

Without fail, if I read about time keeping, I learn something new. I had always thought unix time as the most simple way to track time (as long as you consider rollovers). I knew of leap seconds, but somehow didn’t think they applied here. Clearly I hadn’t thought about it enough. Good post. I also read the link for “UTC, GPS, LORAN and TAI”. It’s an interesting contrast that GPS time does not account for leap seconds.

foobar1962 2y ago
Saying that something happened x-number of seconds (or minutes, hours, days or weeks) ago (or in the future) is simple: it’s giving that point in time a calendar date that’s tricky.
- wodenokoto 2y ago
  Simple as long as your precision is at milliseconds and you don’t account for space travel. We can measure the difference in speed of time in a valley and a mountain (“just” take an atomic clock up a mountain and wait for a bit, bring it back to your lab where the other atomic clock is now out of sync)
- GolDDranks 2y ago
  But because of the UNIX time stamp "re-synchronization" to the current calendar dates, you can't use UNIX time stamps to do those "delta seconds" calculations if you care about _actual_ amount of seconds since something happened.
- miki123211 2y ago
  > Saying that something happened x-number of [...]days or weeks) ago in the future) is simple It's not, actually. Does 2 days and 1 hour ago mean 48, 49 or 50 hours, if there was a daylight saving jump in the meantime? If it's 3PM and something is due to happen in 3 days and 2 hours, the user is going to assume and prepare for 5PM, but what if there's a daylight saving jump in the meantime? What happens to "in 3 days and 2 hours" if there's a leap second happening tomorrow that some systems know about and some don't? You rarely want to be thinking in terms of deltas when considering future events. If there is an event that you want to happen on jan 1, 2030 at 6 PM CET, there is no way to express that as a number of seconds between now and then, because you don't know whether the US government abolishes DST between now and 2030 or not. To reiterate this point, there is no way to make an accurate, constantly decreasing countdown of seconds to 6PM CET on jan 1, 2030, because nobody actually knows when that moment is going to happen yet.

computator 2y ago

> POSIX time, also known as Unix time, is the number of seconds since the Unix epoch, which was 1970-01-01 at 00:00:00. … I think there should be a concise explanation of the problem. I don’t think that the definition that software engineers believe is wrong or misleading at all. It really is the number of seconds that have passed since Unix’s “beginning of time”. But to address the problem the article brings up, here’s my attempt at a concise definition: POSIX time, also known as Unix time, is the number of seconds since the Unix epoch, which was 1970-01-01 at 00:00:00, and does not include leap seconds that have been added periodically since the 1970s.

juped 2y ago
It really is the number of seconds that have passed since Unix's "beginning of time", minus twenty-nine. Some UTC days have 86401 seconds, Unix assumes they had 86400. It's wrong and misleading in precisely the way you (and other commenters here) were wrong and misled, so it seems like that's a fair characterization.
jodrellblank 2y ago
Atomic clocks measure time passing. Seconds are a fraction of a day which is Earth rotating, and count 86400 seconds and then roll over to the next day, but Earth's rotating speed changes so how much "time passing" is in 86400 seconds varies a little. Clocks based on Earth rotating get out of sync with atomic clocks. Leap seconds go into day-rotation clocks so their date matches the atomic clock measure of how much time has passed - they are time which has actually passed and ordinary time has not accounted for; so it's inconsistant for you to say "Unix time really is the number of seconds that have passed" and "does not include leap seconds" because those leap seconds are time that has passed.
Calamityjanitor 2y ago
I think you're describing the exact confusion that developers have. Unix time doesn't include leap seconds, but they are real seconds that happened. Consider a system that counts days since 1970, but ignores leap years so doesn't count Feb 29. Those 29ths were actual days, just recorded strangely in the calendar. A system that ignores them is going to give you an inaccurate number of days since 1970.

calrain 2y ago

When storing dates in a database I always store them in Unix Epoch time and I don't record the timezone information on the date field (it is stored separately if there was a requirement to know the timezone). Should we instead be storing time stamps in TAI format, and then use functions to convert time to UTC as required, ensuring that any adjustments for planetary tweaks can be performed as required? I know that timezones are a field of landmines, but again, that is a human construct where timezone boundaries are adjusted over time. It seems we need to anchor on absolute time, and then render that out to whatever local time format we need, when required.

hx8 2y ago
Maybe, it really depends on what your systems are storing. Most systems really won't care if you are one second off every few years. For some calculations being a second off is a big deal. I think you should tread carefully when adopting any format that isn't the most popular and have valid reasons for deviating from the norm. The simple act of being different can be expensive.
semiquaver 2y ago
> and I don't record the timezone information on the date field Very few databases actually make it possible to preserve timezone in a timestamp column. Typically the db either has no concept of time zone for stored timestamps (e.g. SQL server) or has “time zone aware” timestamp column types where the input is converted to UTC and the original zone discarded (MySQL, Postgres) Oracle is the only DB I’m aware of that can actually round-trip nonlocal zones in its “with time zone” type.
- mulmen 2y ago
  As always the Postgres docs give an excellent explanation of why this is the case: https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-TIMEZONES https://www.postgresql.org/docs/current/datatype-datetime.ht...
  - Scarblac 2y ago

SerCe 2y ago

Working with time is full of pitfalls, especially around clock monotonicity and clock synchronisation. I wrote an article about some of those pitfalls some time ago [1]. Then, you add time zones to it, and you get a real minefield. [1]: https://serce.me/posts/16-05-2019-the-matter-of-time https://serce.me/posts/16-05-2019-the-matter-of-time

mmooss 2y ago
You are a developer who works with time and you named your file, "16-05-2019-the-matter-of-time"? :)
- eru 2y ago
  What's wrong with that?
  - lysium 2y ago
    That’s not a standard format. ISO format is yyyy-mm—dd. Also, sorts nicely by time if you sort alphabetically.
    - eru 2y ago
      Yes, I know. But for your personal file names, you can pick whatever you feel like.
  - BrandoElFollito 2y ago
    They wrote it on the 16th of May, or the 5th of Bdrfln, we will never know.
    - eru 2y ago
      Perhaps it's just named for that date, and not written then? In any case, dates only have to make sense in the context they are used. Eg we don't know from just the string of numbers whether it's Gregorian, Julian, or Buddhist or Japanese etc calendar.

quotemstr 2y ago

So what if leap seconds make the epoch 29 seconds longer-ago than date +%s would suggest? It matters a lot less than the fact that we all agree on some number N to represent the current time. That we have -29 fictional seconds doesn't affect the real world in any way. What are you going to do, run missile targeting routines on targets 30 years ago? I mean, I'm as much for abolish leap seconds as anyone, but I don't think it's useful --- even if it's pedantically correct --- to highlight the time discrepancy.

chrchr 2y ago
It matters for some things. Without those fictional leap seconds, the sun would be 29 seconds out of position at local noon, for instance.
- School-Cotton 2y ago
  That does not matter at all to anyone.
  - porridgeraisin 2y ago
    Yeah. "Exact time" people are a bit like "entropy" people in cryptography. Constantly arguing about the perfect random number when nobody cares.
  - growse 2y ago
    Did you ask everyone? It most certainly matters to a lot of people. It sounds like you've never met those people.
    - zokier 2y ago
      For practically everyone the local civil time is off from local solar time more than 30 seconds, because very few people live at the exact longitude that corresponds to their time zone. And then you got DST which throws the local time even more off. This is ignoring the fact that due equation of time, solar noon naturally shifts around tens of minutes over the course of the year. To drive the point, for example local mean solar time at Buckingham palace is already more than 30 seconds off from Greenwich time.

christina97 2y ago

Lot of people seem to miss the point of the article. Suppose you had a clock that counted seconds (in the way we understand seconds, moving forward one unit per second). If you looked at it in a few days at midnight UTC on NYE (according to any clock), it would not be a multiple of 86400 (number of seconds per day). It would be off by some 29 seconds due to leap seconds. In that way, Unix time is not seconds since the epoch.

School-Cotton 2y ago
You have it backwards. If you look at it at midnight UTC (on any day, not just NYE) it WOULD be an exact multiple of 86400. (Try it and see.) Because of leap seconds, this is wrong. Midnight UTC tonight is in fact NOT a multiple of 86,400 real, physical seconds since midnight UTC on 1970-01-01.
- jacobgkau 2y ago
  He didn't have it backwards, he was saying the same thing as you. He said, "suppose you had a clock that counted seconds," then described how it would work (it would be a non-multiple) if that was the case, which it isn't. You ignored that his description of the behavior was part of a hypothetical and not meant to describe how it actually behaves.
  - School-Cotton 2y ago
    You’re absolutely right — not sure how I misinterpreted that so badly.
  - christina97 2y ago
    Thanks but I’m a “she” :)

jonnycomputer 2y ago

I think this article ruined my Christmas. Is nothing sacred? seconds should be seconds since epoch. Why should I care if it drifts off solar day? Let seconds-since-epoch to date representation converters be responsible for making the correction. What am I missing?

christina97 2y ago
The way it is is really how we all want it. 86400 seconds = 1 day. And we operate under the assumption that midnight UTC is always a multiple of 86400. We don’t want every piece of software to start hardcoding leap second introductions and handling smears and requiring a way to update it within a month when a new leap second is introduced. You never worried or thought about it before, and you don’t need to! It’s done in the right way.
- turminal 2y ago
  But most software that would need to care about that already needs to care about timezones, and those already need to be regularly updated, sometimes with not much more than a month's notice.
  - dmoy 2y ago
    I will never forgive Egypt for breaking my shit with a 3 day notice (what was it like 10 years ago?). Thankfully for me it was just a bunch of non-production-facing stuff.
    - kragen 2y ago
      Was this Morsy's government or Sisi's? If it's Morsy's government you're holding a grudge against, I have some good news for you. (Presumably you're not holding that grudge against random taxi drivers and housewives in Alexandria.)
      - dmoy 2y ago

maxbond 2y ago

> ((tm_year - 69) / 4) * 86400 Seems like there's another corner cut here, where the behavior of leap years at the end of a century (where they're skipped if a year is divisible by 100 unless it's divisible by 400) is not accounted for. I suppose using Unix time for dates in the far future isn't a good idea. I guess I'll file that away. (For the curious, the way this seems to work is that it's calibrated to start ticking up in 1973 and every 4 years thereafter. This is integer math, so fractional values are rounded off. 1972 was a leap year. From March 1st to December 31st 1972, the leap day was accounted for in `tm_yday`. Thereafter it was accounted for in this expression.)

growse 2y ago
> I suppose using Unix time for dates in the far future isn't a good idea. I guess I'll file that away. Not just Unix time, converting future local time to UTC and storing that is also fraught with risk, as there's no guarantee that the conversion you apply today will be the same as the one that needs to be applied in the future. Often (for future dates), the right thing to do is to store the thing you were provided (e.g. a local timestamp + the asserted local timezone) and then convert when you need to. (Past dates have fewer problems converting to UTC, because we don't tend to retroactively change the meaning of timezones).
jwilk 2y ago
> the behavior of leap years at the end of a century (where they're skipped if a year is divisible by 100 unless it's divisible by 400) is not accounted for. The article cites the original edition of POSIX from 1988. The bug in question was fixed in the 2001 edition: https://pubs.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html#tag_04_14 https://pubs.opengroup.org/onlinepubs/007904975/basedefs/xbd...

schneehertz 2y ago

This means that some time points cannot be represented by POSIX timestamps, and some POSIX timestamps do not correspond to any real time

marcosdumay 2y ago
Well, at least there isn't any POSIX timestamp that correspond to more than one real time point. So, it's better than the one representation people use for everything.
- brianpan 2y ago
  Not yet.
growse 2y ago
This has always been true. Pre 1970 is not defined in Unix time.
- usrnm 2y ago
  Why? time_t is signed
  - growse 2y ago
    From IEE 1003.1 (and TFA): > If year < 1970 or the value is negative, the relationship is undefined.
  - layer8 2y ago
    In addition to being formally undefined (see sibling comment), APIs sometimes use negative time_t values to indicate error conditions and the like.
  - 8n4vidtmkvmk 2y ago
    Probably because the Gregorian calendar didn't always exist. How do you map an int to a calendar that doesn't exist?

tw1984 2y ago

there is literally no easy and safe way to actually handle leap seconds. what happens when they need to remove one second? even for the easier case of inserted leap second, you can smear it, but what happens if there are multiple systems each smearing it at different rates? I'd strongly argue that you pretty much have to reboot all your time critical and mission critical systems during the leap second to be safe. the issue is so wide spread and complicated that they decided to stop introducing extra leap seconds so people can come up with something better in the coming decades - probably way later than the arrival of AGI.

vendiddy 2y ago

Maybe a naive question but why wasn't the timestamp designed as seconds since the epoch with zero adjustments? Everything would be derived from that. I suppose it would make some math more complex but overall it feels simpler.

growse 2y ago
With hindsight, we'd do lots of things differently :) I guess they just didn't foresee the problem, or misjudged the impact. I can imagine it being very "let's kick that problem down the road and just do a simple thing for now" approach.
- wat10000 2y ago
  UNIX systems at the time probably didn’t care about accuracy to the second being maintained over rare leap second adjustments. Random example, the wonderful RealTime1987A project (https://bmonreal.github.io/RealTime1987A/ https://bmonreal.github.io/RealTime1987A/) talks about detecting neutrinos from the supernova, and what information can be inferred from the timing of the detections. A major source of that data is the Super Kamiokande project. The data was recorded to tape by a PDP-11, timestamped by its local clock. That clock was periodically synced with UTC with a sophisticated high-tech procedure that consisted of an operator making a phone call to some time service, then typing the time into the computer. As such, the timestamps recorded by this instrument have error bars of something like +/- one minute. If that’s the sort of world you’re in, trying to account for leap seconds probably seems like a complete waste of effort and precious computer memory.
fragmede 2y ago
Arguably it's worse if 00:33 on 2024.12.26 has to get run through another function to get the true value of 2024.12.25 T 23:59. The problem is leap seconds. Software just wasn't designed to handle 86401 seconds in a day, and caused incidents at Google, Cloudflare, Quantus, and others. Worried that resolving all possible bugs related to days with 86401 seconds in them was going to be impossible to get right, Google decided to smear that leap second so that the last "second" isn't. And if you've not seen it, there's the falsehoods programmers believe about time article.

zaran 2y ago

I wonder if the increasing number of computers in orbit will mean even more strange relativistic timekeeping stuff will become a concern for normal developers - will we have to add leap seconds to individual machines? Back of the envelope says ~100 years in low earth orbit will cause a difference of 1 second

gavinsyancey 2y ago
Most of those probably don't/won't have clocks that are accurate enough to measure 1 second every hundred years; typical quartz oscillators drift about one second every few weeks.
Rastonbury 2y ago
For GPS at least it is accounted for 38 microseconds per day, they have atomic clocks accurate to like 0.4 milliseconds over 100 years. The frequencies they measure at are different from earth and are constantly synchronised.

paradite 2y ago

Typically you don't need to worry about leap seconds on server because AWS or GCP will help you handle it. You just need to read the docs to understand their behavior. Some will smooth it out for you, some will jump for you. It would be a problem if you have 3rd party integrations and you rely on their timestamp.

mgaunard 2y ago

The timestamps given in the article seem completely wrong? Also, where would 29 even come from? The offset between UTC and TAI is 37 seconds.

possiblywrong 2y ago
You are correct. The first example time in the article, "2024-12-25 at 18:54:53 UTC", corresponds to POSIX timestamp 1735152893, not 1735152686. And there have been 27 leap seconds since the 1970 epoch, not 29.
Retr0id 2y ago
I'm also not sure where 29 came from, but the expected offset here is 27 - there have been 27 UTC leap seconds since the unix epoch.

DrBazza 2y ago

There's a certain exchange out there that I wrote some code for recently, that runs on top of VAX, or rather OpenVMS, and that has an epoch of November 17, 1858, the first time I've seen a mention of a non-unix epoch in my career. Fortunately, it is abstracted to be the unix epoch in the code I was using.

pavlov 2y ago
Apparently the 1858 epoch comes from an astronomy standard calendar called the Julian Day, where day zero was in 4713 BC: https://www.slac.stanford.edu/~rkj/crazytime.txt https://www.slac.stanford.edu/~rkj/crazytime.txt To make these dates fit in computer memory in the 1950s, they offset the calendar by 2.4 million days, placing day zero on November 17, 1858.
- deleted 2y ago
  [deleted]
- hanche 2y ago
  It’s called the modified Julian day (MJD). And the offset is 2,400,000.5 days. In the Julian day way of counting, each day ended at noon, so that all astronomical observations done in one night would be the same Julian day, at least in Europe. MJD moved the epoch back to midnight. https://en.wikipedia.org/wiki/Julian_day https://en.wikipedia.org/wiki/Julian_day
spiffytech 2y ago
There's an old Microsoft tale related to the conflict between Excel's epoch of Jan 1 1900 vs Basic's Dec 31 1899: https://www.joelonsoftware.com/2006/06/16/my-first-billg-review/ https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
evmar 2y ago
Another common computing system to be aware of: the Windows epoch is 1-Jan-1601.
NoInkling 2y ago
PostgreSQL internally uses a 2000-01-01 epoch for storing timestamps.

nubinetwork 2y ago

Isn't this the point to the tz files shipped on every linux system? If the crappy online converters only do the basic math formula, of course it's going to be off a little...

xpe 2y ago

Is there a synchronized and monotonically increasing measure of time to be found?

kevindamm 2y ago
Not really. GPS time comes close (at least, it avoids leap seconds and DST) but you still have technical issues like clock drift.

colanderman 2y ago

Note also that the modern "UTC epoch" is January 1, 1972. Before this date, UTC used a different second than TAI: [1] > As an intermediate step at the end of 1971, there was a final irregular jump of exactly 0.107758 TAI seconds, making the total of all the small time steps and frequency shifts in UTC or TAI during 1958–1971 exactly ten seconds, so that 1 January 1972 00:00:00 UTC was 1 January 1972 00:00:10 TAI exactly, and a whole number of seconds thereafter. At the same time, the tick rate of UTC was changed to exactly match TAI. UTC also started to track UT1 rather than UT2. So Unix times in the years 1970 and 1971 do not actually match UTC times from that period. [2] [1] https://en.wikipedia.org/wiki/Coordinated_Universal_Time#History https://en.wikipedia.org/wiki/Coordinated_Universal_Time#His... [2] https://en.wikipedia.org/wiki/Unix_time#UTC_basis https://en.wikipedia.org/wiki/Unix_time#UTC_basis

weinzierl 2y ago
A funny consequence of this is that there are people alive today that do not know (and never will know) their exact age in seconds[1]. This is true even if we assume the time on the birth certificate was a time precise down to the second. It is because what was considered the length of a second during part of their life varied significantly compared to what we (usually) consider a second now. [1] Second as in 9192631770/s being the the unperturbed ground-state hyperfine transition frequency of the caesium 133 atom
- benlivengood 2y ago
  [2] in a particular gravity well.
- deleted 2y ago
  [deleted]

cbarrick 2y ago

> There’s an ongoing effort to end leap seconds, hopefully by 2035. I don't really like this plan. The entire point of UTC is to be some integer number of seconds away from TAI to approximate mean solar time (MST). If we no longer want to track MST, then we should just switch to TAI. Having UTC drift away from MST leaves it in a bastardized state where it still has historical leap seconds that need to be accounted for, but those leap seconds no longer serve any purpose.

phicoh 2y ago
The is no such thing as TAI. TAI is what you get if you start with UTC and then subtract the number of leap seconds you care about. TAI is not maintained as some sort of separate standard quantity. In most (all?) countries, civil time is based on UTC. Nobody is going to set all clocks in the world backwards by about half a minute because it is somewhat more pure. GPS time also has an offset compared to TAI. Nobody care a bout that. Just like nobody really cares about the Unix epoch. As long as results are consistent.
- gerdesj 2y ago
  The only think we can be certain of is that the Summer Solstice occurs when the mid summer sun shines through a trillithon at Stonehenge and strikes a certain point. From there we can work outwards. The logical thing to do is to precisely model Stonehenge to the last micron in space. That will take a bit of work involving the various sea levels and so on. So on will include the thermal expansion of granite and the traffic density on the A303 and whether the Solstice is a bank holiday. Oh bollocks ... mass. That standard kilo thing - is it sorted out yet? Those cars and lorries are going to need constant observation - we'll need a sort of dynamic weigh bridge that works at 60mph. If we slap it in the road just after (going west) the speed cameras should keep the measurements within parameters. If we apply now, we should be able to get Highways to change the middle of the road markings from double dashed to a double solid line and then we can simplify a few variables. ... more daft stuff ... Right, we've got this. We now have a standard place and point in time to define place and time from. No we don't and we never will. There is no absolute when it comes to time, place or mass. What we do have is requirements for standards and a point to measure from. Those points to measure from have differing requirements, depending on who who you are and what you are doing. I suggest we treat time as we do sea level, with a few special versions that people can use without having to worry about silliness. Provided I can work out when to plant my wheat crop and read log files with sub micro second precision for correlation, I'll be happy. My launches to the moon will need a little more funkiness ...

ZeroCool2u 2y ago

More often than I care to admit, I yearn for another of Aphers programming interview short stories. Some of my favorite prose and incredibly in depth programming.

ck2 2y ago

I would not be on a plane or maybe even an elevator mid-January 2038 if it can do this to cloudflare, imagine everything left on legacy signed 32bit integers https://blog.cloudflare.com/how-and-why-the-leap-second-affected-cloudflare-dns/ https://blog.cloudflare.com/how-and-why-the-leap-second-affe...

ascorbic 2y ago

I just finished reading "A Deepness in the Sky" a 2000 SF book by Vernor Vinge. It's a great book with an unexpected reference to seconds since the epoch. >Take the Traders' method of timekeeping. The frame corrections were incredibly complex - and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth's moon. But if you looked at it still more closely ... the starting instant was actually about fifteen million seconds later, the 0-second of one of Humankind's first computer operating systems.

jvanderbot 2y ago
That is one of my favorite books of all time. The use of subtle software references is really great. I recommend Bobiverse series for anyone who wants more "computer science in space" or permutation city for anyone who wants more "exploration of humans + simulations and computers"
- nnf 2y ago
  I’ll second the Bobiverse series, one of my favorites. Its descriptions of new technologies is at just the right level and depth, I think, and it’s subtly hilarious.
  - noja 2y ago
    The audio books are narrated brilliantly too. Stange fact: bobiverse has no dedicated Wikipedia page.
    - MobileVet 2y ago
      Ray Porter, the narrator, is quite the talent. He does a brilliant job with ‘Project: Hail Mary’ as well which is the second book from the author of ‘The Martian.’ It has quite a bit more science and humor than The Martian and is one of my favorites.
  - MobileVet 2y ago

prmph 2y ago

The more I learn about the computation of time, the more unbelievably complex getting it right seems. I thought I was pretty sophisticated in in my view of time handling, but just in the last couple of months there have been a series of posts on HN that have opened my eyes even more to how leaky this abstraction of computer time is. Pretty soon we'll have to defer to deep experts and fundamental libraries to do anything at all with time in our applications, a la security and cryptography.

sarusso 2y ago

I remember hearing at a conference about 10 years ago that Google does not make use of leap seconds. Instead, they spread them across regular seconds (they modified their NTP servers). I quickly searched online and found the original article [1]. [1] https://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html https://googleblog.blogspot.com/2011/09/time-technology-and-...

jhalstead 2y ago
Their public NTP doc for the "leap smear" also includes some other leap smear proposals: https://developers.google.com/time/smear https://developers.google.com/time/smear

odyssey7 2y ago

What we’re seeing is again the scientists trying to constrain a humanist system into a scientifically precise framework. It doesn’t really tend to work out. I’m reminded of the time that a bunch of astronomers decided to redefine what a planet is, and yet the cultural notion of Pluto remains strong. Science and culture will rarely move hand-in-glove, so the rule of separation or concerns, to decouple human experience from scientific measurement, applies.

gregfjohnson 2y ago

I've been trying to find discussion of this topic on Hacker News between October 1582 and September 1752, but to no avail. 'cal 9 1752' is .. funny. I guess instead of doing this annoying a-periodic leap second business, they accumulated a bunch of leap seconds owed, and skipped 11 days at one go. Sysadmins at the time were of divided opinion on the matter.

_kst_ 2y ago

Leap seconds should be replaced by large rockets mounted on the equator. Adjust the planet, not the clock.

_1tem 2y ago
It'd be not-so-funny if there was a miscalculation and the Earth was slowed down or sped up too much. There's a story about the end of times and the Antichrist (Dajjal) in the Muslim traditions where this sort of thing actually happens. It is said that the "first day of the Antichrist will be like a year, the second day like a month, and third like a week", which many take literally, i.e. a cosmic event which actually slows down the Earth's rotation, eventually reversing course such that the sun rises from the West (the final sign of the end of humanity).

willvarfar 2y ago

The advantage of equal-length days is that know now what some future date represents; whereas if counting leap-seconds too etc you might get a different date computing now compared to future code that knows about any leap seconds between now and then.

srijan4 2y ago

Somewhat related: I really like Erlang's docs about handling time. They have common scenarios laid out and document which APIs to use for them. Like: retrieve system time, measure elapsed time, determine order of events, etc. https://www.erlang.org/doc/apps/erts/time_correction.html#how-to-work-with-the-new-api https://www.erlang.org/doc/apps/erts/time_correction.html#ho...