[HN Gopher] Time is an illusion, Unix time doubly so
___________________________________________________________________
Time is an illusion, Unix time doubly so
Author : nickweb
Score : 192 points
Date : 2022-10-26 10:00 UTC (13 hours ago)
(HTM) web link (www.netmeister.org)
(TXT) w3m dump (www.netmeister.org)
| kortex wrote:
| Bottom line is: time is quite complicated, and things get messy
| when you try to overload different usages or engineering
| constraints. Including but not limited to:
|
| - small, limited, and/or fixed data size
|
| - compatibility across systems
|
| - range of expressable times
|
| - monotonicity (either locally or distributed)
|
| - express absolute datetimes accurately
|
| - express relative offsets accurately
|
| - accurate over very short or very long timescales (or both)
|
| - synchrony to solar noon
|
| - synchrony to sidereal time
|
| - timezones
|
| - relativisitc effects
|
| Pick any, uhhh, well pick as many as you can and try to shoehorn
| them together and you get your typical time implementation.
| mannykannot wrote:
| _" On Unix systems we measure time as the number of seconds since
| "the epoch": 00:00:00 UTC on January 1st, 1970.... this
| definition is not based on something sensical such as, say, the
| objective frequency of vibration of a Cesium-133 atom, but on a
| convenient fraction of the time it takes a particular large rock
| to complete a full rotation around its own axis."_
|
| Well, seconds have not been defined as "a convenient fraction of
| the time it takes a particular large rock to complete a full
| rotation around its own axis" for quite some time, and the origin
| is set to an abstract event in the past, which is not (as far as
| I know) subject to retroactive revision as a consequence of the
| vagarities of planetary or celestial motion (if it is, I would be
| fascinated to know more.)
| krisoft wrote:
| > seconds have not been defined as "a convenient fraction of
| the time it takes a particular large rock to complete a full
| rotation around its own axis" for quite some time
|
| That is true.
|
| > origin is set to an abstract event in the past
|
| That is also true.
|
| > which is not (as far as I know) subject to retroactive
| revision as a consequence of the vagarities of planetary or
| celestial motion
|
| I'm afraid you are wrong on that. The unix time is synced with
| UTC. UTC has so called "leap seconds" scheduled at irregular
| intervals by the International Earth Rotation and Reference
| Systems Service to keep it in sync with the Earth's actual
| movements. So in effect the unix timestamp is wrangled to sync
| with the Earth's motion.
|
| > if it is, I would be fascinated to know more
|
| https://en.wikipedia.org/wiki/Unix_time#UTC_basis
|
| https://en.wikipedia.org/wiki/Leap_second
| mannykannot wrote:
| Thanks for the correction, this is quite important. I had
| taken statements that Unix and Posix time excludes or ignores
| leap seconds to mean that it increases monotonically in a
| continuous manner in sync with whatever atomic clock is the
| standard; on the contrary, it recognizes and implements leap-
| seconds with a discontinuity deviating from the steady tick
| of that standard.
|
| Examples:
| https://en.wikipedia.org/wiki/Unix_time#Leap_seconds
|
| I also learned that 00:00:00 UTC on 1 January 1970 is a
| proleptic time, as UTC was not in effect then, though I am
| not sure that makes it subject to subsequent planetary
| motions.
| whoville wrote:
| > The unix time is synced with UTC
|
| No, it isn't. The very article you linked explains that Unix
| time is monotonically increasing and ignores leap seconds.
| cellshade wrote:
| "Unix time numbers are repeated in the second immediately
| following a positive leap second. The Unix time number
| 1483142400 is thus ambiguous: it can refer either to start
| of the leap second (2016-12-31 23:59:60) or the end of it,
| one second later (2017-01-01 00:00:00)."
|
| From the linked article.
| lazide wrote:
| That's a very recent change - and it's not like 9192631770
| transitions/hz (which is hilariously self referential!) is some
| obvious, natural value that ISN'T based on the historic
| 'typical' length of the day based on our rotation around the
| sun.
|
| A second being 1/86400th of a day (24 hrs * 60 minutes * 60
| seconds per minute) is still essentially true, and based,
| essentially still on the seasons and our movement around the
| sun (or relative movements between the various bodies in the
| solar system, depending).
|
| Being a chaotic natural system, we of course need to add fudge
| factors here and there to simplify the math day to day while
| keeping it aligned with observed reality, like leap seconds and
| all), at least where it intersects with reality in a material
| way.
| epicide wrote:
| > it's not like 9192631770 transitions/hz ... is some
| obvious, natural value
|
| No, but it is a phone number in the Raleigh area.
| jsymolon wrote:
| And would be awesome if it gave out the current time.
| 1970-01-01 wrote:
| UNIX time, like all times, is a very good one, if we but know
| what to do with it. -Ralph Waldo Emerson
| mlichvar wrote:
| The article missed an opportunity to describe how spectacularly
| can things break when the 32-bit time_t overflows in Y2038.
|
| If you still have such a machine (preferably without any valuable
| data), try setting the date right before the overflow with this
| command
|
| date -s @$[2**31 - 10]
|
| and see if you can recover the system without reboot.
|
| I have seen different daemons stopped responding and just
| consuming CPU, NTP clients flooding public servers, and other
| interesting things. I suspect many of these systems will still be
| running in Y2038 and that day the Internet might break.
| wongarsu wrote:
| Factories are full with machines that get replaced every couple
| decades, and that run software setups even older. Roughly a
| decade ago I was involved in the development of an embedded
| system for industrial use, and the approach to Y2038 was
| "doesn't matter, I'll be retired by then". The system is still
| sold.
|
| I wouldn't be surprised if a lot of companies will handle it by
| just setting the clocks back 50 years or so on industrial
| equipment. But God have mercy on those that forget some
| systems.
| mjevans wrote:
| Most of these systems probably don't even care about the real
| time... so it'd just be more effective to map them back to a
| different index and handle it with an offset externally.
|
| https://en.wikipedia.org/wiki/Doomsday_rule
|
| At a glance it looks like 1971 and 1993 might be good
| alternatives for 2038. The command line cal program agrees
| with where dates start each month for all three years.
| masklinn wrote:
| Fwiw, https://en.wikipedia.org/wiki/Perpetual_calendar
| _kst_ wrote:
| > date -s @$[2*31 - 10]
|
| A digression: The documented bash syntax for arithmetic
| expansion is $(( EXPRESSION )) . I see that $[ EXPRESSION ]
| also works, but I don't see it documented anywhere. (Both
| syntaxes also work in zsh.)
| OliverJones wrote:
| A long time ago -- late 1980s -- I worked in system software,
| VMS-based, at DEC.
|
| Sometimes we used, for dev and testing, dedicated machines
| running with clocks set 20-25 years in the future. (They was a
| measurable investment of capital, power, and cooling back then.)
| This was smart: the remnants of DEC were able to sidestep the
| whole Y2K cluster**k.
|
| Are our key tech vendors doing the same now? It's about a quarter
| century until the 2038 fin-de-siecle. I sure would like some
| assurance that the OSs, DBMSs, file systems, and other stuff we
| all adopt today will have some chance of surviving past
| 2038-01-19.
|
| I know redefining time_t with 64 bits "solves" the problem. But
| only if it gets done everywhere. Anybody who's been writing
| programs for more than about 604 800 seconds has either thought
| through this problem or hasn't.
| sirmike_ wrote:
| Time is a flat circle.
| gpderetta wrote:
| Please. Time is obviously a cube.
| jzl wrote:
| I was surprised to learn that Linux has a "2262 problem" because
| of 64-bit time being used to store nanoseconds rather than
| seconds. That seems like a huge problem without an easy solution
| either. Yes there are almost 250 years to fix it but it seems
| like surprisingly bad planning. In any case it's an interesting
| thought exercise to imagine what the fix should be.
| tonmoy wrote:
| Why is it bad planning? I can't think of a better alternate
| plan.
| jzl wrote:
| It's bad planning because 64-bit time stamps were supposed to
| provide coverage for "22 times the expected lifetime of the
| universe", but by being the only OS to use those 64 bits to
| count nanoseconds, they only bought a couple more bits over
| 32-bit timestamps. What they could have done differently is
| not used nanoseconds for the epoch counter. Milliseconds seem
| like they would have offered the perfect balance.
| chipsa wrote:
| Windows uses 100 nanosecond resolution for NTFS time
| stamps.
| thesuitonym wrote:
| Do you think we'll still be using the same computer systems
| then?
| jzl wrote:
| We're only about 60-70 years into the age of computing and
| have no idea how long legacy software systems will truly
| last. Also imagine uses cases like exploratory or orbiting
| spacecraft which might have useful shelf lives into the
| triple digits.
| nrvn wrote:
| From Beat The Devil (1953):
|
| Time. Time. What is time? Swiss manufacture it. French hoard it.
| Italians squander it. Americans say it is money. Hindus say it
| does not exist. Do you know what I say? I say time is a crook.
| hwskdjf wrote:
| Great blog post. Sometimes it's useful while testing to set
| random future and past times on Unix systems to see how programs
| handle that.
|
| https://blog.darkinfo.org/timestomp-for-linux/
| pfarrell wrote:
| Mongodb, for one, will freak out if you set the system date
| into the future, interact with it, then set time back. It will
| think the indices are corrupt and refuse to start. At least
| that happened to me last year. IIRC, the time stamp is part of
| generated object ids, so it's sort of understandable. In the
| end I returned by computer to the future date, exported data,
| and rebuilt my collections.
| samatman wrote:
| So anyone can bring down Mongo with a compromised ntp server?
|
| That's an inconvenient property to have.
| _jal wrote:
| Oh, if you own someone's clock, you can do all sorts of
| damage.
|
| Want to expire everyone's passwords? Blow up their credit
| card processing? Those are just the obvious attacks.
| samatman wrote:
| Yes but bringing down a database should not be among
| those things.
|
| Surely we can agree on that.
| emj wrote:
| There have been patches the last ten years to lessen the impact
| of 2038, considering how close that is this is a bit worrisome.
| Nice to see a comparison of different systems like this, but you
| probably need to track this over time in some way. E.g Pretty
| sure Gnu date has seen patches about this in the last years.
| runjake wrote:
| Site is getting hammered: https://archive.ph/eUeFa
| NKosmatos wrote:
| Excellent write up, with very nice humorous style and clearly
| explaining the situation with the year 2038 problem.
| seanc wrote:
| From the GNU coretutils doc [1]:
|
| Our units of temporal measurement, from seconds on up to months,
| are so complicated, asymmetrical and disjunctive so as to make
| coherent mental reckoning in time all but impossible. Indeed, had
| some tyrannical god contrived to enslave our minds to time, to
| make it all but impossible for us to escape subjection to sodden
| routines and unpleasant surprises, he could hardly have done
| better than handing down our present system. It is like a set of
| trapezoidal building blocks, with no vertical or horizontal
| surfaces, like a language in which the simplest thought demands
| ornate constructions, useless particles and lengthy
| circumlocutions. Unlike the more successful patterns of language
| and science, which enable us to face experience boldly or at
| least level-headedly, our system of temporal calculation silently
| and persistently encourages our terror of time.
|
| ... It is as though architects had to measure length in feet,
| width in meters and height in ells; as though basic instruction
| manuals demanded a knowledge of five different languages. It is
| no wonder then that we often look into our own immediate past or
| future, last Tuesday or a week from Sunday, with feelings of
| helpless confusion. ...
|
| --Robert Grudin, Time and the Art of Living.
|
| [1]
| https://www.gnu.org/software/coreutils/manual/html_node/Date...
| photochemsyn wrote:
| For even more fun, take a look at this excellent post on GPS,
| and in particular, the time problem:
|
| https://ciechanow.ski/gps/#time
|
| > "When it comes to the flow of time on those satellites, there
| are two important aspects related to Einstein's theories of
| relativity. Special relativity states that a fast moving object
| experiences time dilation - its clocks slow down relative to a
| stationary observer. The lower the altitude the faster the
| satellite's velocity and the bigger the time slowdown due to
| this effect. On the flip side, general relativity states that
| clocks run faster in lower gravitational field, so the higher
| the altitude, the bigger the speedup is."
|
| > "Those effects are not even and depending on altitude one or
| the other dominates. In the demonstration below you can witness
| how the altitude of a satellite affects the dilation of time
| relative to Earth..."
|
| There's also a nice if complex explanation of why your GPS
| receiever needs four satellite emitters to calculate the time
| bias of its clock.
| seanc wrote:
| What a find! That's a top notch GPS explanation; simple,
| detailed and great visualization of complex stuff. Thanks!
| alvarlagerlof wrote:
| Check out the rest of the site
| senko wrote:
| ICYMI: The title is a reference to The Hitchhiker's Guide to the
| Galaxy:
| https://en.m.wikipedia.org/wiki/The_Hitchhiker%27s_Guide_to_...
| ("time is an illusion, lunch time doubly so")
| lproven wrote:
| There are multiple HHGTTG references in it, as is the author's
| Twitter bio:
|
| > Vell, I'm just zis guy, you know?
|
| (A quotation from Gag Halfrunt, Zaphod Beeblebrox's "personal
| brain care specialist".)
| russellbeattie wrote:
| >= _that represents a date around 292 billion years in the
| future, or roughly 22 times the estimated age of the
| universe, and thus officially Somebody Else 's Problem._
|
| And another... (Also, given Adams wrote a few Dr. Who
| episodes, one which turned into Life, the Universe and
| Everything, the "Time Lords" reference could be another.) The
| "Oh, and one more thing" is a slight misquote of, "And
| another thing."
|
| As DNA is my favorite author bar none, I like this post a
| lot.
| Rygian wrote:
| Also the opening paragraph, paraphrasing "In the beginning the
| Universe was created. This has made a lot of people very angry
| and been widely regarded as a bad move."
| ElfinTrousers wrote:
| There is one kind of time that is real and important. That is
| naptime.
| [deleted]
| state_less wrote:
| The article makes a passing reference to atomic clocks, which are
| fascinating. The folks over at MIT are working on improved clocks
| that can get below 100ms error over the the current lifespan of
| the universe.
|
| https://news.mit.edu/2022/quantum-time-reversal-physics-0714
| zokier wrote:
| On different side it's very cool that atomic clocks are these
| days small and cheap enough to put on a pcie card
| https://engineering.fb.com/2021/08/11/open-source/time-appli...
| dis-sys wrote:
| very interesting stuff. wondering is there any in-depth
| walkthrough of the time keeping mechanisms in Linux?
| Koshkin wrote:
| What a mess. (Plus, time is relative, i.e. it depends on the
| frame of reference.)
| gjulianm wrote:
| Maybe I am misunderstanding the post, but for me the beauty of
| Unix time is precisely that all the weirdness with dates is
| abstracted away to the "conversion code" so that you only deal
| with "seconds". Timezones, leap seconds... all of that only
| matters when you're showing the user a date. For recording and
| calculations, it doesn't.
| CodesInChaos wrote:
| > leap seconds
|
| Unix time is UTC based, so it ignores leap seconds and deviates
| from how many seconds actually passed since the start of the
| epoch.
|
| The actual number of seconds passed corresponds to TAI, but you
| can't convert future timestamps from TAI to UTC since you can't
| predict leap seconds, so you can't display future TAI
| timestamps using typical date notation.
|
| > For recording and calculations, it doesn't.
|
| Depends on what you're recording and calculating. Storing a UTC
| timestamp generally works when recording an event that already
| happened.
|
| But it doesn't work for scheduling events like meetings, since
| there the authoritative time is often local time. If you simply
| store such future events in UTC you'll run into problems when
| the definition of the relevant timezone changes.
| adrian_b wrote:
| You can easily "display future TAI timestamps using typical
| date notation".
|
| Both past timestamps and future timestamps are not exact
| numbers, but approximate numbers, affected by errors.
|
| The only difference between past timestamps and future
| timestamps that are converted from TAI to UTC is in the
| magnitude of the errors.
|
| If the past timestamps have been acquired on a computer whose
| clock had been synchronized by NTP, then the errors are
| likely to be less than 10 millisecond.
|
| If the past timestamps have been acquired on a computer whose
| clock had not been synchronized with a precise source, then
| the errors are likely to be greater than a second and they
| may be as large as of several minutes.
|
| For future timestamps, the uncertainty of the value of the
| difference between TAI and UTC makes the likely value of the
| errors to be of several seconds, and increasing with the
| distance of the timestamp in the future.
|
| In conclusion, one must be aware of the probable magnitude of
| the errors affecting an UTC timestamp, but that does not
| prevent conversions between TAI and UTC, whenever that is
| desired.
|
| One of the greatest mistakes when dealing with time values is
| handling them like they were exact values, which they are
| not.
|
| To handle future timestamps with minimal errors, it is
| necessary to have 2 distinct data types, a TAI time expressed
| as a number of some time units, e.g. nanoseconds, and an UTC
| time that is a structure containing date and time of the day.
| An UTC time must never be expressed as a number of seconds
| from some past date. That is the huge mistake made by the
| "UNIX time".
|
| Future timestamps must be stored using the appropriate data
| type, e.g. UTC time for a future scheduled meeting.
|
| The hardware clocks and the low-level clock synchronization
| and handling programs should always use TAI time.
|
| When the current time approaches a future UTC timestamp, the
| error of the estimation of the corresponding TAI time
| diminishes. The leap seconds are announced with many months
| in advance, so the correct TAI time for a future UTC
| timestamp will also be know with at least a few months in
| advance. There is no risk that you computer will fail to
| notify you about the right time of the meeting, except when a
| naive programmer handles the timestamps wrongly, which is
| unfortunately quite frequent.
| ericpauley wrote:
| _deleted_
| CodesInChaos wrote:
| Fixed, thanks. I always confuse those.
| yakubin wrote:
| Unix time is not UTC-based. It counts the number of seconds
| passed since a certain point in time, which may be described
| as date and time expressed in any time zone you like. It just
| so happens that in UTC it is easiest to remember for a human
| what this point was, since you get a lot of zeroes at the
| end.
|
| Edit: I'm not entirely correct here, as aside from UTC the
| time zone, there is also UTC the time standard. See below.
| ericpauley wrote:
| Unix time is UTC-based, in that the leap second corrections
| applied to UTC are also simultaneously applied to Unix time
| (as people tend to use it).
| yakubin wrote:
| I stand corrected. As I've double-checked now,
| unfortunately "UTC" is ambiguous in that it may refer
| both to the time standard and the time zone. In this case
| one can say that Unix time is based on UTC the time
| standard, but not the time zone. Although given that in
| Unix time every day has the same number of seconds and
| instead the clock is sometimes slowed down, while in UTC
| there is an additional 61st second, can we truly say that
| it's UTC-based? I'd say it's its own standard derived
| from UTC. Maybe that's being too pedantic.
| shagie wrote:
| > 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.
|
| Excerpt From _A Deepness in the Sky_ by Vernor Vinge
| friendzis wrote:
| > Timezones, leap seconds... all of that only matters when
| you're showing the user a date. For recording and calculations,
| it doesn't.
|
| You cannot, by definition, tell how many Unix seconds later
| "third of may, 2025, at noon, local time" is - there is no way
| to convert future, local times to Unix times, because that
| "conversion code" is not fixed. Sure, we can reasonably expect
| that definition of time flow relationship to local time will
| not change for _past_ dates, but one _must_ expect these
| changes for times in the future.
| icehawk wrote:
| Is there a system that does allow you do to do this? I can't
| think of one that would.
|
| Local time requires a time zone, times zones are defined in
| relation to UTC, and there is an unknown number of leap
| seconds between now and 3 May, 2025.
| aumerle wrote:
| That's true regardless of how you choose to encode time and
| is a problem of local time zones not unix time.
| friendzis wrote:
| Not really. Generally, you can tell whether "fifth of
| November, at midnight, local time" is equal to `now` or not
| as long as you have reasonably accurate information what
| "local" means. This _is_ a problem of time encoding,
| because we do define what midnight is, but keep
| relationship between it and seconds passed undefined as
| long as possible
| zokier wrote:
| UNIX timestamps are horrible. You can not do calculations with
| them, with fractional part they do not sort correctly, and you
| actually can not reliably convert them back and forth to iso
| timestamps. Basically to do anything useful, you need
| additional bit carried along the timestamp to tell if its leap
| second or not, which is extremely awkward and most APIs do not
| support that.
| fnordpiglet wrote:
| This is why I eat Unix time for lunch.
| thomashabets2 wrote:
| Very interesting detail about linux and setting the time back to
| a value such that the boot time is before the epoch, with
| monotonic clocks.
|
| Shamelessly I'll here remind people to never use gettimeofday()
| to measure time. E.g. setting the time backwards used to cause
| any currently running "ping" command to hang. (they fixed it
| about 10 years after I sent them a patch)
|
| More fun examples of bugs like that at
| https://blog.habets.se/2010/09/gettimeofday-should-never-be-...
| sumtechguy wrote:
| I have made that same mistake a few times myself.
|
| It comes from a natural inclination of I want something to
| expire some period from now.
|
| The natural way is to say what time is it now. Figure out what
| time you want to expire with a date add. Then busy wait until
| that time expires using some form of gettime. The very big
| assumption you make is that the gettime methods always move
| forward. They dont.
|
| This bug is easy to make thinking you are treating a wait item
| as a calendar event. Its not. You need to find something to
| busy wait on, that always counts up. Do not use the system
| clock. Also pick something that counts at a known fixed rate.
| Not all counters are equal. Some can skew by large margins
| after an hour and triggering when you do not expect. Which
| makes people want to reach for the system clock again. If you
| somehow decide 'i _will_ use the clock ' be prepared for some
| pain of the dozens of different ways that fails.
| a_shovel wrote:
| I'm still of the opinion that handling leap seconds by ignoring
| them is a dumb idea.
|
| Unix time should be a steady heartbeat counting up the number of
| seconds since midnight, January 1 1970. Nice, clean, simple. How
| you might convert this number into a human-readable date and time
| is out of scope/implementation-defined/an exercise for the
| reader/whichever variation of "not my problem" you prefer.
| Tuna-Fish wrote:
| > Unix time should be a steady heartbeat counting up the number
| of seconds since ...
|
| This is nice and clean, so long as you have exactly one
| computer. The second there are more than one, and they are
| talking to each other, their clocks can go out of sync with
| each other. And they will, because they are physical systems
| that are imperfect and in general much less precise than you'd
| expect them to be.
|
| This means that there has to be a way to correct for errors.
| The best method, that almost everyone who manages a lot of
| computers converges onto, is to "smear out" any errors, by
| never discretely changing the time on any machine, but just
| shortening or lengthening seconds slightly to bring any
| outliers back to the correct values. And once you have this
| system, dealing with a leap second using it is the easiest,
| simplest and least errorprone method.
|
| I do think that there are purposes where local "machine time",
| which is just a monotonic clock counting upwards from bootup,
| would make sense. Especially when subsecond accuracy is
| important. But it should always be clear that there is _no_ way
| to reliably convert between that and wallclock or calendar
| time. There are *no* intervals of calendar /wallclock time that
| reliably convert to any interval of machine time. It is not
| guaranteed that any wallclock minute contains exactly 60
| machine seconds.
| 10000truths wrote:
| Applications that are require clock synchronization across
| multiple machines should be maintaining their own clock
| anyways, independent of the system clock. NTP for
| millisecond-order precision, atomic clock time cards for
| microsecond-order precision.
| hinkley wrote:
| I think people forget how often computers in the 80's and
| 90's were turned off, keeping track of time with a backup
| battery, and just how many machines had a dead backup battery
| and users that didn't know any better.
|
| I fielded tech support questions from an app that had grown
| to send email. Every week we got a couple of emails from some
| time on January 1, 1970, each from a new person, and a whole
| slew of people whose batteries were on the edge of failing
| and so their machine was days or months off from reality.
|
| The HTTP 1.0 spec already had a solution for two machines
| with different ideas of the current date. It's one of my
| favorite parts of the spec and I've used it a few times in
| order to avoid having to implement my own time negotiation
| protocols (or in fact to stop others from doing it).
|
| I don't think that battery chemistry has changed all that
| dramatically since that time. It was still a 2032 cell, for
| machines that have a discrete battery. Instead it's the clock
| chip and network time protocols that have gotten more
| efficient, and we use the machines more consistently. Or at
| least the machines where time counts matter the most are on
| all the time.
| dhosek wrote:
| There was a Cray installation in Japan in the late 80s or
| early 90s which was reportedly turned off at night to save
| electric costs.
| e12e wrote:
| > The HTTP 1.0 spec already had a solution for two machines
| with different ideas of the current date.
|
| I can't recall noticing this, and can't seem to find
| anything about it in[1] - could you elaborate?
|
| [1] https://www.w3.org/Protocols/HTTP/1.0/spec.html#Date
| hinkley wrote:
| You've found it, or very nearly. The very next section is
| Expires:
|
| > The format is an absolute date and time as defined by
| HTTP-date in Section 3.3.
|
| The implication is subtle but critical. When the server
| sends a Date header and an Expires header, you don't
| expire the content when the local time exceeds the
| Expires Header. You expire it at
| LocalTime + (Expires - Date)
|
| That covers not only time zones but also clock drift.
| When the client is sending data such as a POST, it also
| sends a Date header. That can account for time zones,
| clock drift, and to an extent network latency. When
| you're legally bound to establish the order of events in
| a distributed system someone has to be the source of
| truth, and even when you're not it's still good to have
| for your own purposes. The system of record is the only
| thing that is running on the same clock as the system of
| record, so it is the most sensible source of truth.
|
| So when a client sends you a buffer full of dated events,
| you can (and should) consider the timestamps in the POST
| body as relative to the Date header, not your local
| system time. Otherwise someone running on brown power or
| old school power saving mode will screw up all of the
| timelines in your data.
| masklinn wrote:
| > You expire it at LocalTime + (Expires - Date)
|
| Which makes for a wonky mess, and I guess is why Cache-
| Control did away with the entire thing and just tells you
| how long the response is fresh.
| hinkley wrote:
| Not as wonky as you'd think, and 60 minutes means
| something much different than 12:15. Which can be good
| and it can be bad, but many of my experiences with TTLs
| have not been pleasant. 60 minutes, as typically
| implemented, means some user out there has data that is
| 1:58 stale and he's yelling at your boss on the phone who
| is now trying to figure out if he should be passing the
| favor along.
|
| See also ETags which stop trying to be clever about dates
| and instead be clever about the contents of the message.
|
| Why I like the Date header is that it works well with
| REST endpoints that care about time but for whom caching
| is either not a good idea or is orthogonal.
| haberman wrote:
| What is the actual benefit of this?
|
| The cost is that conversion to/from civil time is far more
| complicated, and worse, cannot be computed for future dates for
| which leap seconds have not yet been determined.
|
| I think that 86,400-second days with a 24-hour leap smear hits
| a sweet spot of utility and usability:
| https://developers.google.com/time/smear
|
| There are very few applications that will know or care that
| seconds get 0.001% longer for 24 hours.
| hinkley wrote:
| How many times a second do computers communicate notions of
| time between each other, versus to a human? We're talking
| many orders of magnitude here, and inequalities like that
| always change the winning strategy.
| wongarsu wrote:
| Skipping or smearing leap seconds means conversion to/from
| civil time is simple ... as long as you only want an accuracy
| of +-1 second.
|
| If you need better conversion, you have to know how the
| system chose to handle leap seconds. If it smears, you have
| to know and implement the smear algorithm, if it doesn't then
| some unix timestamps will map to two different points in
| civil time (second 59 and 60 in any hour with a leap second).
|
| For 99.9% of applications, it's not a bad tradeoff. But if
| we're willing to fudge time by up to a second, recording time
| in TAI (just count a second every second) and living with
| future dates sometimes being off by a couple seconds when
| converted to UTC isn't that different in terms of
| utility/usability tradeoff, and conceptually simpler.
| marcosdumay wrote:
| If you need better precision, you don't go converting
| to/from civil time, because people think on quanta of ~1
| second and better precision is not defined there.
|
| Instead, I'll put my rule here: It's perfectly reasonable
| to drop your time precision to ~1 second when converting it
| into "people time", and you should never expect better
| precision from a back conversion.
|
| That's not saying you don't need TAI. It's just not
| reasonable to mix it and UTC et. al. If you need TAI, you
| live in TAI.
| andrewaylett wrote:
| It sounds like you're looking for TAI:
| https://en.wikipedia.org/wiki/International_Atomic_Time
| spirographer wrote:
| Loved the article! There are so many great details such as the
| standardization of UTC happening after UNIX time invented, UNIX
| itself being born before the epoch, and all the great insight
| into the morass of 64 bit time across modern OSes.
|
| Putting on my pedantic hat though, I see that East and West were
| switched in the discussion of Japan's unique 50/60Hz AC frequency
| split, and I can't get my mind off it. Hope you can make the
| edit.
| [deleted]
| Dave3of5 wrote:
| Worked for a company recently that does test equipment for timing
| and sync.
|
| I was surprised to see that very few systems other than computer
| (servers and suchlike) use unix timestamps. So GNSS systems have
| their own representation of time and the protocols that most
| network equipment uses is called PTP. Now-a-days most are trying
| to use the white rabbit protocol.
|
| I was at a conference on this and there are a lot of crazy
| applications of these timing and sync technologies. The main is
| in 5G networks but the high frequency trading companies do all of
| there trading in FPGAs now to reduce time to make a decision so
| accurate timing is essential. Even the power companies are need
| high accuracy time to detect surges in powerlines. I spoke to
| someone from Switzerland who said they had serious security
| concerns as the timing fibres are poorly secured and open to easy
| disruption.
|
| It was a very interesting domain to work in even though I only
| was do the app part of the thing. Didn't pay enough though and I
| was promised a promotion that never came.
| throw0101a wrote:
| > _So GNSS systems have their own representation of time and
| the protocols that most network equipment uses is called PTP._
|
| It's not so much that (Ethernet?) network equipment uses PTP,
| but rather to get the accuracies desired (+-nanoseconds) there
| needs to be hardware involved, and that makes baking it into
| chips necessary. It's an IEEE standard so gets rolled into
| Ethernet.
|
| Applications for PTP are things like electrical grid and cell
| network timings. Most day-to-day PC and server applications
| don't need that much accuracy.
|
| Most office and DC servers generally configure NTP, which gives
| millisecond (10^-3) or tens/hunderds-microsecond (10^-6)
| accuracy. Logging onto most switches and routers you'll
| probably see NTP configured.
|
| To get the most out PTP (10^-9) you need to generally run a
| specialized-hardware master clock.
___________________________________________________________________
(page generated 2022-10-26 23:01 UTC)