[HN Gopher] UTC, Tai, and Unix Time (2001)
___________________________________________________________________
UTC, Tai, and Unix Time (2001)
Author : enz
Score : 118 points
Date : 2024-05-09 08:40 UTC (14 hours ago)
(HTM) web link (cr.yp.to)
(TXT) w3m dump (cr.yp.to)
| umanwizard wrote:
| Leap seconds make no sense and we should just permanently stop
| doing them.
|
| It really doesn't matter if UTC drifts away from solar time by an
| hour every few thousand years.
| mihaic wrote:
| Why are people downvoting this comment? Genuinely curious
| what's not to agree with here.
| AlecSchueler wrote:
| I'd guess it's because it's the usual hubris, that a software
| engineer's loose thoughts are worth more than the wisdom of
| experts in the field. It writes off all the current work as
| simply useless without giving any defence of that position
| etc.
| umanwizard wrote:
| Okay, what do you think is useful about leap seconds?
| GJim wrote:
| Without them, one can compare the eventual correction
| that _will_ be required to bring our clocks back into
| line with the Earth (and our biology!) akin to the shift
| from the Julian to Gregorian calendar?
| umanwizard wrote:
| No, it would just require time zone changes, which
| already happen a few times a year which we already know
| how to deal with (the TZ db).
| AlecSchueler wrote:
| I'm not sure why you think I'm qualified to give a
| suitable answer to this.
|
| Did you ask the person above to explain why they aren't
| useful?
| umanwizard wrote:
| Okay, fair enough. I'll elaborate. Here's why I don't
| think they're useful: leap seconds exist to align
| standard time with the sun. But humans are the only ones
| who care about sun alignment; computers don't. And the
| effect of leap seconds is so microscopic that it doesn't
| matter to humans, especially since the alignment is
| inexact anyway (solar noon is never at exactly 12:00 PM
| on any given day except at one particular line of
| longitude per time zone). For getting it roughly aligned,
| which is what humans care about, we already have time
| zones with fixed, rarely-changing offsets from UTC, which
| I am not proposing we get rid of.
|
| Since leap seconds don't help for subjective human needs,
| and they _also_ don't help for computers, science,
| engineering etc. (if you care deeply about solar noon for
| some technical reason you should use something that
| tracks it more precisely than UTC anyway), I can't think
| of anything they _are_ useful for, except for saving our
| descendants thousands of years from now from having to
| change time zones when it drifts far enough to matter,
| which I think is a speculative and not very compelling
| reason.
|
| I'd happily change my opinion if I heard a good reason
| for keeping them, so I object to claiming that this is
| "hubris".
| AlecSchueler wrote:
| Thanks, that sounds quite reasonable to the untrained
| ear.
|
| Just wanted to say I didn't downvote the original
| comment, I was only trying to guess about how others were
| perceiving it.
| ttepasse wrote:
| > (solar noon is never at exactly 12:00 PM on any given
| day except at one particular line of longitude per time
| zone)
|
| According to the 20. amendment the term of an US
| president starts at Noon, 20 Januar. Simply noon. The USA
| seems to interpret it as 12:00 ET and makes it ceremonial
| inauguration for that time, possibly also the transfer of
| powers. But solar noon on the steps of the Capitol seems
| to be at 12:18 ET, I researched back at the last
| inauguration.
|
| This discrepancy seems to be a great premise for a legal
| thriller, a political thriller, or sadly for a conspiracy
| theory. The latter definitely has some fertile ground.
|
| The americans should start using the Washington Monument
| as a solar clock for this ceremony, imo.
| bloak wrote:
| It's something people have strong opinions on. Obviously some
| people want to get rid of leap seconds but I personally like
| UTC with leap seconds. The only change I'd make is to require
| leap seconds to be announced several years in advance (which
| would require allowing a slightly bigger divergence between
| UTC and UT1). Computer systems should gradually migrate to
| using TAI internally, but a clock on the wall or a bus
| timetable should using something like UTC: something that,
| you know, stays in sync with the actual sun. Saying "oh we'll
| shift all the time zones around one day" isn't an acceptable
| solution as far as I'm concerned. And I don't believe leap
| minutes would work any better than leap seconds: in fact I'm
| fairly certain they would be a whole lot worse.
|
| Anyway, that's an explanation of my opinion. Many people will
| disagree with it.
| umanwizard wrote:
| > Saying "oh we'll shift all the time zones around one day"
| isn't an acceptable solution as far as I'm concerned.
|
| Why not? Time zones change constantly. Dealing with
| changing time zones is something we already know how to do
| easily.
| bloak wrote:
| I don't think it's true that "changing time zones is
| something we already know how to do easily". At least not
| with the word "easily" in there. Time zones cause a lot
| of problems, which is why we don't change them
| constantly. And it would be nice to have a future in
| which time zones are changed even more infrequently
| rather than one in which they have to be changed to
| things like UTC-37:00 because they are specified in terms
| of a UTC that has become unmoored from the diurnal cycle
| of day and night.
|
| But probably the main argument against getting rid of
| leap seconds from UTC is that we already have TAI for
| anyone who wants something like UTC but without the leap
| seconds. In fact we already have two things that are like
| UTC but without the leap seconds: there's TAI and there's
| also GPS time, offset from TAI by 19 seconds. If that's
| what you want, use TAI. Or use GPS. What's the points of
| adding a third kind of time that is just like those two
| but offset by yet another small constant offset?
|
| I tend to think that there's a real use for something
| like UTC that stays in sync with the Earth's rotation
| (and thus with the diurnal cycle of day and night) and
| that if some coterie of bureaucrats turns UTC into
| another version of TAI/GPS then probably someone else
| will at some point have to invent another thing to
| replace UTC and then we'll be roughly back where we
| started just with extra confusing complexity.
|
| Imagine you want to specify the date and time of an
| international online meeting. Today you'd probably use
| UTC for that. But if most of the world were more than 24
| hours offset from UTC then using UTC would mean
| specifying the "wrong" date for the meeting. You probably
| wouldn't want to do that so instead you'd use whatever
| new thing has been invented to replace UTC, something
| that has leap seconds or leap minutes or leap hours (or
| leap days?) or some other way of staying in sync with the
| calendar. Leap seconds seems to me like the right
| granularity: they're small enough to be ignored for most
| everyday purposes, and frequent enough that programmers
| can't just pretend they don't happen.
|
| (Sorry for the waffle ... I didn't intend to write that
| much. I should definitely care less about this seeing as
| whatever happens I'll be dead long before the shit hits
| the fan.)
| umanwizard wrote:
| It will take something like 5,000 years for solar time to
| drift from TAI by more than an hour. Given that time
| zones change a few times a year in random parts of the
| world (for example, eastern Kazakhstan changed from UTC+6
| to UTC+5 to unify with the rest of the country this
| year), adding another occasion to change them every few
| thousand years makes no meaningful difference.
|
| Your example of getting so far off that we have to change
| _days_ would take several times longer than the distance
| between the invention of agriculture and now. Honestly, I
| would be extremely surprised if human civilization
| survives that long, but even if it does, our descendants
| can just deal with the problem then. There's no reason to
| make our lives more difficult _now_ just to deal with
| this very niche hypothetical scenario.
| GJim wrote:
| It's disappointing to see a well made argument like yours
| downvoted on HN.
|
| Downvoting is meant for text that detracts from the
| conversation. Not as a tool for suppressing well made
| arguments one disagrees with.
| s_dev wrote:
| Chesterton's Fence. Why were they invented and implemented?
|
| That has to be justified before scrapping something we don't
| necessarily understand and a lot of programmers are just
| grateful we have libraries to handle this complexity for us.
| GJim wrote:
| > Why were they invented and implemented?
|
| Because one cannot ignore nature?
|
| I suspect the vast majority of those programmers who have
| problems with leap seconds should really be using (and are
| unaware of) TAI.
| coldtea wrote:
| > _Because one cannot ignore nature?_
|
| Sure we can, in computing make abstractions that ignore
| nature all the time. As long as there's no issue (or no
| big issue) with them being out of sync, we're fine.
|
| Besides there are few things natural about how we handle
| time, those are already big towers of abstractions on top
| of the movement of celestial bodies that simplify and
| sidestep a lot of subtleties.
| zarzavat wrote:
| The world doesn't use TAI. If I'm making a train booking
| app and the train departs at 21:50 in Germany in the
| summer, it's not departing at 21:50 TAI+2, it's departing
| at 21:50 UTC+2. So you cannot avoid using UTC.
|
| Programmers simply deal with the world as it exists.
| Every single country uses UTC therefore that is how time
| must be represented. It is easier to remove leap seconds
| from UTC than it is to make all countries adopt TAI at
| the same instant.
|
| The concept of leap seconds can of course be preserved by
| defining a new time standard that isn't called "UTC".
| lazide wrote:
| TAI is 'a second always takes the same amount of time,
| and the number of seconds is always increasing'. Which is
| really useful in the real world when tracking/counting
| events every second all the time.
|
| Because leap seconds cause weird gaps or overlaps
| (depending on how they are happening).
|
| This doesn't matter for pretty much anyone who doesn't
| track/log/act every second all the time in a way where if
| a second 'disappears' or happens twice or takes longer on
| one day than on another it's noticeable.
|
| When monitoring or tracking large scale systems, it's a
| really irritating problem, which is why TAI is nice and
| exists in computer land. Also why it's nice for many
| scientist types.
|
| For everyone else, something like UTC layered on top is
| more than good enough. Leap seconds are fine enough
| there. Same with most timezones, and PDT/PST, etc.
| eviks wrote:
| The comment justifies it no worse than how the Fence
| principle is justified
| aragilar wrote:
| I'd argue any system that's affected by leap seconds should be
| using TAI, and accepting that showing users the time (or
| accepting user input) is going to require an up-to-date table
| of conversions (it's not like a leap second is any bigger of a
| deal than the various changes to timezones).
| mavhc wrote:
| Exactly, we already store and show dates and times
| differently due to time zones, just add seconds to that
| alteration too. we have tzdb, add lsdb for leap second
| database and we can work out the difference for any time in
| the past, or near future
| eyelidlessness wrote:
| At that point, why not just move leap seconds entirely into
| local time as part of the time zone offset? Track each time
| zone's initial, current, and (inevitable for at least some
| locales) final leap second offset. Include it directly in
| the numeric expression of the offset. Freeze UTC at the
| initial offset, update the relevant specs to provide for
| this, and call it effectively "done", where "done" is that
| leap seconds are an entirely human-facing, local-
| jurisdiction-governed concern, entirely _derived from_
| monotonically incrementing base time.
| CryZe wrote:
| You are right, and whenever we drifted by 1 hour (or whatever
| is deemed too much) we can just update each time zone in the
| TZDB to be different by that amount of time going forward. This
| shifts the problem from a basically unsolved one (with how no
| OS properly supports TAI) to a solved one, time zones.
|
| You could even align it with a DST transition in countries that
| have those where you simply skip one to apply the change.
| tiagod wrote:
| Hopefully we get rid of DST in the next 1000 years...
| lazide wrote:
| Don't bet on it. Leap years were systematized/invented in
| 46 BC and are still here, and DST is a thing due to
| seasonal cycles which aren't going away either.
| seanhunter wrote:
| With you on this. Also (in probably increasing order of
| controversy):
|
| 1)daylight savings should be completely abolished. It just
| causes confusion.
|
| 2)timezones should be completely abolished. They also cause
| confusion. If you live in California, instead of getting up at
| say 8am you get up at say 3pm. There is never any confusion
| with anyone globally about scheduling anything.
|
| 3)Months should be the same length. Instead of 12 months of 30,
| 31, 28 or sometimes 29 days, with a varying number of weeks in
| each month depending on the year, you have exactly 13 months of
| 4 weeks each (28 days). 13*28=364 which gives you an extra day
| "New years day" or "Christmas day" or whatever but that isn't a
| day of the week. If it's a leap year the day after that
| Christmas day is "Leap day" and it also isn't a day of the
| week. Then a particular date is always the same day of the
| week, months are all 4 weeks, quarters are exactly 3 months and
| 1 week each and have the same end dates every year etc. Tons of
| benefits.
|
| Literally the only downside people come up with when I mention
| it is "yeah but imagine if your birthday is now a Monday, that
| would SUCK!"
| darrenf wrote:
| > _2)timezones should be completely abolished. They also
| cause confusion. If you live in California, instead of
| getting up at say 8am you get up at say 3pm. There is never
| any confusion with anyone globally about scheduling
| anything._
|
| But, err, "am" and "pm" refer to where the sun is in the sky.
| That's their literal meaning. It's useful information.
| Timezones are (obviously) a physical thing. Abolishing them
| to aide the comparatively tiny number of people worldwide who
| need to schedule a phone call with someone in another country
| is pretty bonkers IMO.
|
| Furthermore, I don't want to be booking a flight home from
| Australia to the UK, pick a 9am departure from SYD only to
| discover it's in the evening.
| seanhunter wrote:
| That meaning is a human construction. It already doesn't
| mean where the sun is in the sky in the current location,
| it means in a single specific location per timezone. We
| could just agree that it means "where the sun is in the sky
| in Greenwich, UK"[1]
|
| [1] Notionally. Obviously the sun is not often in the sky
| in London.
| eviks wrote:
| 2 will continue causing confusion: "is it ok to schedule this
| for 1pm or is that too early in California?"
| seanhunter wrote:
| That already exists. It is my daily life in fact. eg "Is
| 8am PST too early for folks in IST?" literally is all day
| every day.
|
| For example I literally have 3 emails in my inbox at the
| moment that arrived overnight from people in California
| saying some variation on "I saw a slot in your calendar for
| xpm PST, is that too late for you in London?".
| umanwizard wrote:
| The set of people who care about anything that using one
| time zone for everyone would fix (mainly programmers who
| have to deal with time zone conversions) is much smaller
| than the set of people who care about the things it would
| break: anyone who wants to understand the shared global
| culture around local times (for example: anyone who
| travels to other time zones regularly, or even anyone who
| watches foreign movies or TV and wants to understand what
| the characters are talking about when they mention time
| of day).
|
| That's why I support getting rid of leap seconds, but not
| getting rid of time zones: the number of people who leap
| seconds helps is very small (possibly zero) since their
| effect on everyday life is microscopic.
| seanhunter wrote:
| Yeah I know. I'm not actually seriously entertaining the
| hope that 2 or 3 happen. Eliminating DST would be I think
| also be a genuine benefit to almost everyone with very
| little downside.
| calfuris wrote:
| People are going to keep living their lives approximately
| according to local solar time, which means that the
| meaning of X time in practical terms ("is this a good
| time to call?") is going to be different from place to
| place, so people would need some way of looking up the
| normal schedule of a particular location. And now we've
| re-invented time zones but probably with slightly
| different details, meaning that we can't just re-use the
| old time zone tracking infrastructure as is.
| growse wrote:
| > 2)timezones should be completely abolished. They also cause
| confusion. If you live in California, instead of getting up
| at say 8am you get up at say 3pm. There is never any
| confusion with anyone globally about scheduling anything.
|
| Good luck selling a large swaithe of humanity that Tuesday
| will turn into Wednesday at some point during their working
| day.
| planede wrote:
| That's what TAI is for. Too bad nobody got the memo and
| everybody stores and communicates UTC, including computer
| clocks, UNIX time and NTP.
|
| There will be no more leap seconds after 2035, AFAIK.
| umanwizard wrote:
| Sure. So my argument is that everything should use TAI, and
| local time zones should be an offset from TAI, not UTC
| (because local times are primarily for humans, and humans
| don't care about extremely slow time zone drift that leap
| seconds are designed to prevent). Then we can abolish UTC
| entirely since it serves no purpose.
| planede wrote:
| The problem isn't really about handling local time. UTC is
| an offset from TAI and time zones are offsets from UTC,
| it's overall really just an offset from TAI. Coordinating
| the TAI-UTC offset is not any worse than coordinating time
| zone offsets.
|
| The complications are around clocks, UNIX timestamp and
| NTP, where a steadily and monotonously increasing number
| would make the most sense, and that's not UTC.
| lazide wrote:
| Good news, the 2038 Unixtime mess should give some
| impetus on cleaning this all up before then.
| fanf2 wrote:
| The people in charge of leap seconds agree, and they are in the
| process of being abolished. The ITU World Radiocommunication
| Conference last year confirmed their part; the next stage is
| the CGPM in 2026.
|
| https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-TF.2511-2022...
|
| https://www.itu.int/hub/publication/s-gen-news-2023-2/
| nabla9 wrote:
| Leap seconds are eliminated from UTC by 2035.
| umanwizard wrote:
| That's great news.
| rssoconnor wrote:
| Also, if we don't get some calendar reform, by the year 17000,
| the northward (spring) equinox will be around February 23rd.
| gavinhoward wrote:
| Leap seconds should be first-class instead.
|
| https://gavinhoward.com/2023/02/make-the-leap-second-first-c...
| aragilar wrote:
| I'm surprised TAI isn't more widely used, given it hardcodes many
| of the assumptions programmers have about time.
|
| Sidenote, "Tai" in the title should be TAI.
| the_mitsuhiko wrote:
| Is it really surprising? In practice people care about the time
| on the wall and to get that from TAI you need to maintain a
| leap second database.
| aragilar wrote:
| That's no different to maintaining a timezone database
| though, and leap seconds are more coordinated than timezone
| changes.
| the_mitsuhiko wrote:
| I don't need a timezone database to track UTC.
| aragilar wrote:
| What are you using as a time source, because I guarantee
| that source has said mapping (from TAI or GPS time or
| whatever timescale it actually getting the raw data for)?
| the_mitsuhiko wrote:
| UTC to a time people use / is legally mandated does not
| require knowledge of leap seconds as UTC takes care of
| it. So for all intents and purposes with UTC you can
| ignore that leap seconds exist.
|
| TAI to a time people use requires knowledge of all leap
| seconds as you otherwise end up significantly
| desynchronized.
| coldtea wrote:
| You do need it to do show that UTC value in local time,
| which most systems (except maybe server logs) eventually
| need.
|
| And you still need leap seconds list for UTC.
| zokier wrote:
| The kernel needs to maintain leap database for POSIX time
| too, so that it knows when to do those double-seconds
| re wrote:
| Typically operating systems don't maintain a database but
| instead rely on network time servers to let them know that
| a leap second is about to occur.
| djbusby wrote:
| Not everyone has a network
| the_mitsuhiko wrote:
| The clock of machines is not reliable enough anyways most
| of the time. You end up having to reset them anyways.
| wodenokoto wrote:
| Don't you need that to calculate UTC as well? If you want to
| go back 30 seconds from 1st of January, 00:00:10 UTC, you
| need to know if the previous year had 60 or 61 one seconds in
| its last minute.
| toast0 wrote:
| Yes, but most people are using POSIX time (intentionally or
| not). You don't need a database in POSIX time.
| FObersteiner wrote:
| I guess we still like solar time a lot ;-) The point is, for
| date/time calculations, you need a numeric representation that
| increases strictly monotonically (an epoch time). If you
| introduce unpredictable modifications to that (leap seconds),
| the nice calculation falls apart, you end up with a lookup
| table such as the one in the IANA timezone database / TZif
| files (the blog post calls it the Olson library).
| groestl wrote:
| That's because a lot of people have the misconception about
| UTC, that it works like TAI. If you think your tool already
| does what you like, even though it doesn't, you're not looking
| for anything else.
| michaelt wrote:
| That's because for a great many purposes, _doing things the way
| everyone else does them_ is an extremely big benefit.
|
| If your operating system uses UTC, your logging library uses
| UTC, your SSL cert issuer uses UTC, your TOTP tokens use UTC,
| your NTP client uses UTC, your e-mail headers use UTC, your
| string formatter uses UTC, your serialised data parsing
| libraries use UTC, everyone who sends you data uses UTC, and
| everyone you send data to wants to receive UTC - why swim
| against the current?
|
| How do I know this? Because I've tried it. Let me assure you,
| for every bug you avoid using TAI, you'll experience 500 bugs
| due to UTC/TAI confusion.
| re wrote:
| Note that this page was written in 2001; the leap second
| situation has gotten a lot more complicated since then, with far
| more diverging implementations that handle it differently, and no
| real momentum towards widespread adoption of software that
| handles them "correctly" (explicitly), like the localtime() "fix"
| preferred by DJB.
|
| Most people seem to prefer ignoring leap seconds, pretending they
| don't exist by "smearing" them across the surrounding day, or
| even getting rid of them entirely.
| https://news.ycombinator.com/item?id=33658541
| https://news.ycombinator.com/item?id=32226414
| planede wrote:
| At least leap seconds will be eliminated by 2035, so there is
| that. Computers were never good at dealing with it. Keeping
| computer clocks in UTC instead of TAI and rewinding it for leap
| seconds was always insane. The same goes for UNIX time and NTP.
| GJim wrote:
| > At least leap seconds will be eliminated by 2035
|
| The arrogance of programmers who think it is possible to
| ignore reality to suit them :-)
|
| I suspect the reality is many are unaware of TAI which would
| be more than 'good enough' and make life much easier for
| them.
|
| EDIT: Downvotes simply for stating facts and opinions from
| outside the IT industry hardly prompts useful discussion!
| blueflow wrote:
| Not programmers, the BIPM: https://www.bipm.org/documents/2
| 0126/64811223/Resolutions-20... Page 24 / Resolution 4
| GJim wrote:
| Input to BIPM to abolish leap seconds was overwhelmingly
| from the IT industry.
| michaelt wrote:
| Does anyone deal with leapseconds _without_ it being
| mediated by computers?
| GJim wrote:
| Computers (and those who programme them) are there to
| serve humans (with a biology regulated by the Earth), not
| the other way around!
| tialaramex wrote:
| No. UTC with leap seconds isn't "reality" except in the
| sense that some of those awful scripted "reality TV" shows
| are reality. It's a confection, and it's annoying so
| there's no real argument for it beyond "That's what we've
| always done" which is a pretty dubious rationale for
| anything, but even more so when it's been like that for
| less than a normal human lifespan.
|
| Leap seconds won't even be like the automobile, let alone
| newspapers or hotdogs, they're a fleeting idea we thought
| might be good, now we realise it's not good, so bye bye.
|
| There are two "realities" here. TAI is the monotonically
| increasing "Seconds are the same length and happen in
| order" clock time that it turns out well suits a lot of
| human enterprises. The exact details have been worked out
| pretty well. A Day in TAI is 24 hours of 60 minutes of 60
| SI seconds, always, forever.
|
| UT1 is a descendant of "Solar time" now based on the
| Earth's rotational angle. A Day in UT1 is the full
| rotation, how long that is in SI seconds varies very
| slightly and arbitrarily.
|
| UTC wants to have the steady monotonicity of TAI except it
| wants to match UT1's days exactly, this is not a thing, so
| the "leap seconds" are conjured to kludge it. This kludge
| is what's going away, it's not part of "reality" it's a
| kludge to try to fit a square peg in a round hole and we're
| giving up the kludge.
|
| It has been a _long_ time since humans worked purely from
| direct observation of the "solar time" or rotation. Once
| the clock gets invented, so millennia ago, that's out and
| humans are measuring (albeit not very precisely at first)
| what we now call TAI. Giving up leap seconds is us finally
| accepting that while UT1 is astronomically interesting,
| it's not actually a sensible basis for day to day living.
| GJim wrote:
| > while UT1 is astronomically interesting, it's not
| actually a sensible basis for day to day living.
|
| Hard disagree!
|
| Allowing ones clocks to gradually drift from the
| behaviour of the Earth (which regulates our biological
| lives) is a mess. Once can compare the eventual
| correction that _will_ be required akin to the shift from
| the Julian to Gregorian calendar and the problems that
| caused.
|
| TAI was always there for those who needed it.
| zarzavat wrote:
| A leap minute every few centuries makes much more sense
| than a leap second every few years. We have until our
| great-great-grandchildren to prepare.
| GJim wrote:
| That really is the _motherload_ of technical debt.
|
| This discussion really is highlining the cultural
| differences between software engineers and other
| engineering fields.
| zarzavat wrote:
| Not really. Adding leap seconds at the end of years is
| inferior because a year is a human-scale duration.
|
| Planning something "next year" is human-scale. Planning
| something "next century" is not human-scale because I
| won't be alive then.
|
| If we use leap minutes then most people will not see one
| in their lifetime, compared to everyone seeing multiple
| leap seconds in their lifetime.
| ChrisSD wrote:
| But when that leap minute does eventually occur, it's
| going to cause havoc in all the systems that don't handle
| it. Which, let's face it, there are going to be a lot of.
| Either because they were never designed for it or else
| the relevant code paths were never actually tested.
| mminer237 wrote:
| You could broadcast a leap minute with a decade to
| prepare for it and most software would still be
| developed, used, and die off in the 90 years in between.
| It's better for 15% of relevant software to have to worry
| about something so consequentially minor than 100%.
| throw0101d wrote:
| > _A leap minute every few centuries makes much more
| sense than a leap second every few years. We have until
| our great-great-grandchildren to prepare._
|
| People can't get the _regular_ changes of DST and
| February 29 correct, and you want them to get a _one-off_
| change right?
|
| I'd rather 'inflict' change (semi-)regularly so people at
| least _try_ to get things right and get some practice, as
| opposed to a Hail Mary pass /change in some distance
| future.
| zarzavat wrote:
| We already have rules that are much rarer and more
| impactful than leap minutes would be. For example on Feb
| 29th 2000 an entire extra day was inserted on a century,
| an event that only happens once every 400 years! It was a
| complete non-event and only time nerds remember that it
| happened.
|
| In the case of a leap minute, the worst that can happen
| is that your clock is 1 minute out every couple of
| centuries. Doesn't seem so bad and certainly much better
| than dealing with leap seconds every few years.
|
| We don't need to constantly rehearse for such an event,
| we can just do nothing and die without worrying about it.
| Gare wrote:
| It was a non-event because 2100 will actually be an "odd"
| one, divisible by four but not a leap year.
|
| Every dumb implementation that looked at division by 4
| got 2000 right.
| 01HNNWZ0MV43FF wrote:
| Please no just let it drift
| marcosdumay wrote:
| If we are still using the same calendar in 60000 years,
| and if the Earth's Sun is still so important that we have
| to adjust our watches, we can start to talk about a leap
| day.
|
| Granted, this is some 100 times longer than our calendar
| has lived. And some 10 times longer than any human
| calendar. So, I suggest we postpone the issue a bit.
| gavinhoward wrote:
| And yet, they won't, or won't be able to.
|
| Leap seconds allow leap second bugs to be fixed in one
| generation. Leap minute bugs need cross-generational
| debugging.
|
| https://gavinhoward.com/2023/02/make-the-leap-second-
| first-c...
| zamadatix wrote:
| The drift (a second every ~1.5 years) is so small the
| accumulation is irrelevant to biological processes. 2000
| years from now it does not matter that solar time has
| drifted ~an hour. Beyond "what people millennia ago used
| to do at 7 we do at when the clock says 8" not being a
| problem (assuming we even live similar lives) I'll be god
| damned if we can stop ourselves from changing zones and
| whether or not we'll observe DST this year for the next
| 20 years let alone what else we'll muck up in the next
| 2000.
|
| TAI will still be there and needed by folks. UTC is
| stopping adding leap seconds in the future, not reverting
| back as if it never had any.
| throw0101d wrote:
| > _The drift (a second every ~1.5 years) is so small the
| accumulation is irrelevant to biological processes._
|
| It is irrelevant until it is not: just ask Julius Caesar
| and Pope Gregory XIII.
|
| > _Beyond "what people millennia ago used to do at 7 we
| do at when the clock says 8" not being a problem_ [...]
|
| The difference of an hour does make a difference, as
| sleep researchers and chronobiologists keep pointing out
| every time a discussion on DST comes up (it is _not_ just
| about the sudden time jump, but _also_ about the _actual_
| time):
|
| * https://www.frontiersin.org/articles/10.3389/fphys.2019
| .0094...
|
| * https://sleepresearchsociety.org/wp-
| content/uploads/2022/11/...
|
| * https://srbr.org/wp-content/uploads/2018/10/SRBR-
| Statement-o...
|
| * http://www.chronobiocanada.com/official-statements
| 01HNNWZ0MV43FF wrote:
| If a difference of an hour that's been there your entire
| life is noticeable, we should be able to observe that as
| a discontinuity of quality of life at time zone
| boundaries.
| zamadatix wrote:
| > It is irrelevant until it is not: just ask Julius
| Caesar and Pope Gregory XIII.
|
| You're refferring to needing to reform the entire
| calendar but this doesn't make sense in context of me
| explaining that the calendar itself never needs to be
| reformed in the first place. That the sun was a few
| degrees different in the sky for Julius Caesar when a
| modern clock reads 3 PM in his time is not inherently a
| problem as Julius Caesar wouldn't have the same norms as
| you do in terms of what wall time is acceptable for
| waking/sleeping/eating/working/etc. E.g. 20,000 years
| from now if a clock reads 3 AM during midday it' not a
| problem as society will have had 20,000 years to adjust
| 12 hours vs your referenced calendar reforms that changed
| everything overnight.
|
| > The difference of an hour does make a difference, as
| sleep researchers and chronobiologists keep pointing out
| every time a discussion on DST comes up (it is not just
| about the sudden time jump, but also about the actual
| time):
|
| Again, you're missing the forest through the trees -
| though in two different ways here. The first is that it's
| a minute over someone's (long) life, so what impact we
| feel when we change time by an hour twice a year isn't
| relevant. The second is that society, over 2,000 years,
| does not need to change timekeeping itself to wake up
| when the clock says 8 instead of 7. If the change were to
| happen over a short period then sure, it's not really
| feasible for society to move up what wall time their
| breakfast is four times a year or something, but an hour
| a millenia isn't even something society needs to
| consciously worry about.
|
| My point is not that we don't have a biological clock,
| it's that the effect of leap seconds on a human's
| biological clock are too small to affect it. One of your
| sources already says it's 15-20 minutes misaligned a day,
| why are you using it to argue 1 additional minute for
| your entire life is impactful? On the long term societal
| scale my point is society won't always agree we should
| wake up when the wall clock says 7 am. That norm changing
| shifting ~an hour 2,000 years is not a relevant concern
| for changing the way we keep time.
| philwelch wrote:
| > The difference of an hour does make a difference, as
| sleep researchers and chronobiologists keep pointing out
| every time a discussion on DST comes up (it is not just
| about the sudden time jump, but also about the actual
| time)
|
| Do any of these sleep researchers have anything to say
| about France using CET instead of GMT even though CET is
| about an hour off from their natural time? Or Spain being
| on CET despite being almost another hour off from France?
|
| Furthermore, how long is it going to take for the
| accumulated leap seconds to add up to a full hour of
| time? My understanding is that it's on the order of
| centuries. If humanity can maintain an industrialized
| civilization that's capable of keeping track of leap
| seconds for that long, most of us won't even be living on
| the earth by the time it makes any difference.
| amiga386 wrote:
| > UTC with leap seconds isn't "reality"
|
| Weeks aren't reality. Timezones aren't reality.
| Julian/Gregorian calendar months aren't reality. But they
| are essential.
|
| Calendars, centralised time, and timezones drive
| coordinated human socialisation and commerce, increasing
| the wealth of all nations.
|
| Countries have switched timezones so that their "work
| day" matches another more prosperous country's "work day"
|
| Humans want, and have always wanted, a compromise between
| their activities, and the unalterable reality of nature.
| We have "daylight savings time" because if we say "work
| is between 9AM and 5PM", that allows for the synchronised
| commerce - you can phone another business at 9AM because
| you both start work at 9AM, and 9AM = 9AM for both of
| you. But the reality is that in the winter months,
| everyone is going to work or leaving work in darkness,
| with no daylight time for socialisation. So you shift
| your entire country's (or state's) offset from an
| absolute clock, to turn "9AM to 5PM" into "8AM to 4PM"
| without actually stating that, because if businesses
| started varying their hours, they'd desync completely and
| you'd never get business done again.
|
| It hasn't been that long since we accepted centralised
| time, only really since the invention of railways, and
| especially since the invention of the telegraph. Prior to
| that, local solar time ruled. Bram Stoker was particulary
| upset that Ireland was 25 minutes out of alignment with
| Great Britain (Dublin Mean Time vs Greenwich Mean Time),
| in his view Ireland was missing out on a lot of trade [0]
|
| I don't think we're going to move to a time source that
| will slowly desync us from nature. If we liked being
| desynced from nature, we've have ditched DST by now - we
| haven't. And we also haven't gone entirely back to nature
| and made it 9:30 in Dublin when it's 9:55 in London. I
| think we're going to remain on this middle path - fudging
| the mixture of atomic time and alignment with solar time
| - for the rest of our days on this planet.
|
| [0] https://www.thefitzwilliam.com/p/turning-back-the-
| economic-c...
| lifthrasiir wrote:
| Leap seconds were accepted only because they were better
| than the previous solution (the "rubber second") and not
| enough people complained. It's just that we finally got
| enough complaints that they are being abolished. AND the
| end result is TAI being universally accepted, with a fixed
| offset due to the historical reason though :-p
| GuB-42 wrote:
| It is not just about programmers, it is just that the Earth
| is not considered an accurate enough clock anymore. We can
| do better with atomic clocks.
|
| For day-to-day operations, we don't need the exact position
| of the sun in the sky, in fact, with time zones, we can be
| off by hours and still do business. Using the sun would be
| inconvenient anyways, as each location would need its own
| time. So for that, a few seconds is completely negligible.
|
| Not many people care about the precise position of the sun
| in the sky as seen from an arbitrary location, so there is
| no real need to skew our overall more useful atomic clocks
| for this.
|
| Maybe, in a distant future, people will need to update
| their time zones to catch up with what would be a
| noticeable shift, big deal...
| schindlabua wrote:
| Are they really? I wonder why this wasn't bigger news. Anyway
| that's good to hear.
| acqq wrote:
| "Smearing" is much more sensible approach for the use cases
| where it is implemented. There is simply no solution that is
| optimal for every use case, and insisting on using just one
| approach everywhere is unreasonable.
| trwm wrote:
| We stop pretending that universal time exists and add
| location to every time stamp relative to some predefined
| clock at a known location. The issues of when something
| happened dissapear.
| galangalalgol wrote:
| I like the odea of reference frames. But it isn't just
| geographic. The unix clock on a starlink is doing double
| digit mach and goes horizon to horizon in minutes. GPS
| satellites have always had to account for relativity, so we
| could look to that system... Hmm, seems gps time doesn't
| add leap seconds, only using those already added when it
| started ;)
| SAI_Peregrinus wrote:
| Sure, you can define the reference frames to allow any
| orbit on any body. Mars landers & orbiters have slightly
| different time due to general & special relativity than
| Earth's surface, and also don't need Earth
| days/months/years, for example.
| justin_ wrote:
| > UNIX time counts the number of seconds since an ``epoch.'' This
| is very convenient for programs that work with time intervals:
| the difference between two UNIX time values is a real-time
| difference measured in seconds, within the accuracy of the local
| clock. Thousands of programmers rely on this fact.
|
| Contrary to this, since at least 2008[0], the POSIX standard
| (which is just paper not necessarily how real systems worked at
| that time) has said that "every day shall be accounted for by
| exactly 86400 seconds." That means that in modern systems using
| NTP, your Unix timestamps will be off from the expected number of
| TAI seconds. And yes, it means that a Unix timestamp _can repeat_
| on a leap second day.
|
| There's really no perfect way of doing things though. Should Unix
| time - an integer - represent the number of physical seconds
| since some epoch moment, or a packed encoding of a "date time"
| that can be quickly mapped to a calendar day? "The answer is
| obvious" say both sides simultaneously :^)
|
| EDIT: I know DJB is calling out POSIX's choices in this article,
| but it seems like his "definition" does diverge from what the
| count actually meant to a lot of people.
|
| [0] Also: "The relationship between the actual time of day and
| the current value for seconds since the Epoch is unspecified."
| https://pubs.opengroup.org/onlinepubs/9699919799.2008edition...
| zokier wrote:
| > There's really no perfect way of doing things though. Should
| Unix time - an integer - represent the number of physical
| seconds since some epoch moment, or a packed encoding of a
| "date time" that can be quickly mapped to a calendar day? "The
| answer is obvious" say both sides simultaneously :^)
|
| Either way arguably POSIX time is the worst of both worlds, not
| being either of those. This is one of those cases where
| middleground compromise is worse than either option. Having
| datetime be just 15:17 bit structure (date:time_of_day) or more
| practically just int:int struct, it would be infinitely better
| than current POSIX time. Or just have it be plain SI seconds
| since epoch counter would also be better than POSIX time. Or
| even have both options available. There are so many better
| options, it is almost baffling how POSIX ended up with the
| worst possible one
| zzo38computer wrote:
| My opinion is to use a dual structure which is how I had
| considered in my operating system design: a signed 64-bit (or
| possibly longer) number of seconds, and a 32-bit number of
| nanoseconds (which is not always present; sometimes the
| precision of nanoseconds is unknown or unnecessary, so it would
| be omitted). There are then separate subtypes of timestamps,
| such as UTC (which allows the number of nanoseconds to exceed
| one billion) and SI (which does not allow the number of
| nanoseconds to exceed one billion). Which is appropriate
| depends on the application.
| bloppe wrote:
| That's an interesting approach, but not without pitfalls. You
| can't just subtract two timestamps to get a time difference,
| since there may have been one with 2 billion nanoseconds
| somewhere in between.
| zzo38computer wrote:
| This is true. However:
|
| - You can subtract two SI-based timestamps to get a SI-
| based time difference. This will give you the correct
| number of nanoseconds.
|
| - You can subtract two UTC-based timestamps to get a UTC-
| based time difference. This will not give you a number of
| nanoseconds.
|
| Note that, if you have a list of when leap seconds are,
| then you can convert between SI-based and UTC-based
| timestamps which are counted from the epoch; in this way it
| is possible to get a SI-based time difference from UTC-
| based timestamps if you need it.
|
| It is not as simple as just subtracting them of course, but
| if your application is meant to use precise time
| differences then you can just use SI-based timestamps
| instead of UTC-based timestamps, so that you can simply
| subtract them from each other. Programs that need to deal
| with days and calendars instead, are likely to prefer to
| use UTC-based timestamps instead.
| bloppe wrote:
| I've spent literally hundreds of hours thinking about this, and
| I've landed on the opinion that TAI should always be the source
| of truth. It's usually not, because most systems ultimately get
| their source of truth from the GPS system, which uses something
| that looks kind-of like UTC (but is actually more similar to
| TAI, but people prefer to dress it up as UTC). This was a
| reasonable mistake that has caused so many problems due to the
| leap seconds.
|
| If you're using TAI, it's more obvious that you have to account
| for leap seconds in order to convert to a human-readable civil
| time format (year, month, day, hour, minute, second). You know
| that you have to incorporate the official leap second list from
| IANA or some other authority. UTC makes it seem simpler than it
| actually is, and that's why there are so many problems.
|
| You can always convert from TAI to civil time. You cannot
| always go the other way.
| prmoustache wrote:
| Ultimately, I think nobody cares anymore about POSIX.
| zzo38computer wrote:
| I am not sure about that. POSIX has some benefits, and its
| features are commonly used; however, there are also some
| problems.
|
| There are other operating system specifications too, but I also
| wanted to make one operating system design, and I also wanted
| to avoid many of the problems with POSIX.
|
| I did not konw that POSIX says that 2100 is a leap year, and
| clearly that is no good.
| billpg wrote:
| Pick Two. A. A day is divided into a fixed
| number of smaller units. B. Each smaller time unit is of
| a fixed physical duration. C. The day cycle corresponds
| to the cycle of the solar day on Earth.
|
| TAI picks A and B, allowing the solar cycle to drift from the
| time.
|
| UTC picks B and C, adding leap seconds to keep track with Earth's
| solar day cycle.
|
| UT1 picks A and C, redefining the "second" to the changing rate
| of earth's solar day cycle.
| bxparks wrote:
| And I guess POSIX tries to pick all three, at least most of the
| time. It follows UTC mostly, except during leap seconds when it
| changes the duration of a POSIX-second to be 2 SI-seconds
| (positive leap second) or 0 SI-seconds (negative leap second).
| amiga386 wrote:
| POSIX time_t picks A and C.
|
| 99.999998% of time_t ticks from 1970 until now have been 1
| second long. 27 have been 2 seconds long. Therefore B ("each
| smaller time unit is of a fixed physical duration") is the
| variant.
| bloppe wrote:
| Actually, this sort-of describes "smeared UTC", which is
| used by some computer systems such as Google's NTP servers:
| https://developers.google.com/time/smear
|
| POSIX time does not generally work that way. It may seem
| that way for 1-second resolution timestamps, but at higher
| resolutions (say millisecond resolution), the clock does
| not completely stop. It keeps going, jumps backward 1
| second, then continues.
| dexwiz wrote:
| Another way to think about it is that UTC is a combination of
| UT1 and TAI. It's kept within 1 second of UT1 and is always a
| fixed integer offset from TAI.
|
| TAI is an absolute time based on atomic vibrations. UT1 is a
| relative time based on astrometric systems.
| bloppe wrote:
| It's not a fixed offset from TAI. The offset changes every
| time there's a leap second.
|
| Also, there is no such thing as absolute time, because of
| relativity. We take pains to account for this by only
| measuring TAI on the Earth's geoid, but even so the
| uncertainty never reaches zero. Two "stationary" atomic
| clocks on the geoid are expected to drift by about a second
| every billion years or so. Sure, that's pretty good, but
| definitely no "absolute".
|
| When you _really_ think about it, the cesium atom and the
| earth 's day/night cycle are both equally valid clocks. But
| the cesium atom measures time more similarly to the way we
| perceive time on a small scale. But, of course, our lives are
| scheduled based on the day/night cycle. So they both matter.
| UTC is the way we reconcile the two.
| StableAlkyne wrote:
| > A. A day is divided into a fixed number of smaller units.
|
| > B. Each smaller time unit is of a fixed physical duration
|
| This just gave me Timecube flashbacks
| bloppe wrote:
| Ya, and Unix time decided they could fool people into thinking
| they had all 3, and as a result, every couple of years, time
| "jumps backward" by one second. It's hands down the worst
| option to use as the basis for a computing system that needs
| accurate timestamps, and it's made software developers really
| resent leap seconds.
|
| Now the BIPM decided to "get rid" of leap seconds in UTC a
| couple years ago. I hope they come to their senses before 2035
| when the change takes effect. Here's what will happen:
|
| Rather than inserting a leap second every 1-2 years to keep UTC
| in sync with solar time, they plan to defer the problem to once
| every 100 or so years, and just insert like 50 leap seconds all
| at once. Think about that for a second. If leap seconds are so
| bad, how in the hell is the world going to deal with 50 of them
| at once after a century of oblivious complacency? They won't.
| They'll just say "Look, it's not worth it to have leap seconds
| in UTC anymore". Then, UTC will forever be just a constant
| offset away from TAI.
|
| But we already _have_ TAI. Why not just use TAI as your
| "source of truth", and let UTC be UTC? We'll have to introduce
| a new system to take the place of UTC and be in-sync with solar
| time; like how UTC used to be.
| vbezhenar wrote:
| TAI makes sense on Earth, but when it comes to separate cosmic
| bodies (like Moon base), my mind does not work well enough to
| understand how it would work, when time physically is different
| from the Earth time and even might change if we're talking about
| accelerating rockets. And how one would design a software and
| protocols exchanging instant values between those bodies.
| lazide wrote:
| We'll burn that bridge when we come to it.
| leandrod wrote:
| Quite offensive its characterisation of Posix, given RMS'
| involvement to make GNU viable, as far as memory serves me.
___________________________________________________________________
(page generated 2024-05-09 23:01 UTC)