This is the same as the alarm clock problem. When a user creates an event, what does that user _mean_? In the alarm clock example, what should happen if I've set my alarm clock 7am and then travel to a different time zone? In the conference event example, what should happen if the local time zone rules change, or daylight savings time comes into force? Did the event organiser print marketing materials that said "starts at 1000 UTC" or "starts at 10am" with a "in the local time zone" implication?
Events generally need to be locked to _something_ - whether that is UTC or a local time zone depends on the application.
In situations with ambiguity like this, it's probably best to ask the user instead of make assumptions.
I would not be remotely perturbed if my phone had a pop up when I stepped off the plane asking me if I still wanted to wake up at 7AM local or would prefer to wake up at 10AM UTC.
I would be greatly perturbed if it assumed the latter and I missed my meeting, all because I forgot to set a timezone when I originally inserted it a month prior.
If, at 12:30 AM on a Tuesday, you ask Siri to remind you about something “tomorrow”, Siri will ask if you meant Wednesday or Tuesday. I always thought that was a nice touch.
What do you suggest in situations where you can’t do that? Last summer, I travelled on a sleeper train from Lisbon to Madrid, which are in different time zones. At the time that I set my alarm, my phone had no way of knowing that it would automatically jump an hour ahead in the middle of the night.
In that specific case, it woke me up according to local time, which is what I expected. But what if I had crossed the time zone boundary less than an hour before I wanted to be woken up?
In my experience assuming I think of my calendar as anything other than local time is always wrong. 10+ years of using calendars in different timezones and I have never once meant anything other than “9am when I’m there”
It’s my calendar, why would I set it to events in a way that’s not relative to my time reference?
This is something we (startup insurance company) have thought about a lot actually. Since the certificates we issue are relevant to a particular jurisdiction, if the document states e.g. "23:59:59", it means the "wall clock" time in that jurisdiction - whatever point-in-time our DB contains isn't really that relevant.
So the likely problematic situ is if we've got a policy end date/time more than a year in advance, then the country changes their TZ offsets, we need to make sure our point-in-time records get updated (and then of course the duration of the policy changes). It's a bit of a pain in a system built around immutable events!
On a kinda related note, we also took the decision to clearly define that our start/end date-times have a resolution of one second and are inclusive. So if a policy starts at 00:00:00 and ends at 23:59:59, that's the full day, all the way up to midnight. It also means then it's important that we render the full time (incl seconds) on our docs.
I bet you already know this but for the reader: the solution is to not think of times occurring with an offset but to rely on the IANA timezone database to figure out what a timezone means at a particular UTC time: https://www.iana.org/time-zones
That’s what annoys me about google calendar and most others. When I schedule an appointment most of the times it will be for the time zone i will be in at the time of the appointment. So when I travel and agree to meet people at 10 I want to enter it that way. But in most calendar apps everything gets shifted around as soon as I arrive at the new location. I would much prefer to have apps not shift stuff around unless I explicitly tell the app to do it.
I think what you want, at least on the mobile Google Calendar app is under:
Settings - General - Use device time zone
If you disable this, you'll keep everything pinned to your preferred timezone.
But I'm pretty sure a better approach is to select the timezone of the event. If it is at 10am in Germany, why not tell your calendar about this? Sure, this is an extra step, but it is part of the event's parameters (as pointed out in the OP).
For that you would like to have an explicit "local time zone" option. I had recently similar in application I am developing, with datetime of which we are not sure in which time zone they are. That information might arrive later.
In UI cases like this, I usually wish tech would err on the side of being transparent and predictable rather than trying to be smart. For example, if my alarm has been set to 10:00 (with no attached time zone), it should go off when the clock face reaches 10:00.
I think python3's datetime has something like what you're pointing at -- objects are either timezone-aware or not. My complaint probably has to do with trying to hide this distinction from the user, when it would be more helpful to make it clear.
iCalendar (the Mac app, not the underlying representation) gets this badly wrong. It assumes that all events on the calendar are bound to the time zone that the computer was in when the event was entered. This is decidedly not the Right Thing when I travel. If I schedule an event for 7 AM, what I invariably mean is 7 AM in the local time zone where I am going to be on the day of the event, not on the day that I enter the event.
The upshot is that if I travel and change my Mac's clock to local time, all of my events get screwed up. The first time this happened I nearly had a heart attack because I have years of history in my calendar. So I always leave my Mac's clock set to my home time zone and do the conversion in my head.
With Google calendar that's very easy, there's an option to specify different time zones for a single event's start and end times.
It's also very useful that you can set the left margin (in the web app) to show two different time zones in a "ruler" format. So even if your overseas appointments for later in the week are displayed in terms of your current timezone, a quick glance across will confirm what their "local" time will be once you're on the ground.
Sort of a summarization of most of the ideas here is:
* for clear instants like a system log UTC makes sense
* for times in the past (far enough in the past that you know your current TZ rules are correct) UTC makes sense.
* for the immediate past (near enough where your rules might not be correct) you might want to store zone as well.
For all cases of times in the past, remember that you're trying to record an instant. An exact unambiguous point in time that is the same irrespective of who is looking at it or where they are. For this UTC makes sense - people who see that instant converted to their local timezone are noting what their clocks would have shown at that instant, but everyone who will ever see it is always referencing the same instant.
FUTURE times are very different. There are times at which you want to reference a future instant, at which point you can just use UTC, but most often what you really have is "this is what I expect to see on my wall clock when this thing happens". That is a very different beast, because nobody knows what the timezone rules or geopolitical situation will be when that thing does happen.
You need to recognize the use cases where what you mean is " I expect to see XX:YY:ZZ on my wall clock when this happens" and just record that information as is, including as much information as you can about that wall clock - possibly which timezone it (currently) uses, where it is (in case the timezone itself changes) and then convert to an instant at the last possible moment, or keep updating your instant based on changing rules.
Ran into the "fun" around future dates big time at my previous company.
We allowed users to define schedules which would control light, temperature, co2, irrigation, etc for greenhouses. Those schedules would load into on premise controllers and run for weeks or months.
They might be built by a user in one timezone and deployed to multiple facilities in different timezones. They often ran across DST boundaries, and some users wanted them to follow "wall clock time" while others wanted to ignore DST to match the behavior of legacy control systems.
There is one thing that I ran into with past times that I think falls outside of this. When you record things like “first day of employment”, you really do mean the date and not the datetime, and the date should be interpreted in whatever the local timezone is. Theoretically your first datetime if employment is what, midnight of the day you show up? Or is it 8am or whatever when you actually first step through the door? Each situation will be interpreted differently by the parties involved so best you can do is to store the date and the location/timezone of where they work, even though it’s in the past.
Yeah, a date and datetime / instant are two very different things, but I just renewed an insurance policy, and while it's been all dates on the forms so far the actual policy documents is clear about midnight to midnight on those dates.
In the particular case of employment I'd assume there was as implicit time as well, because employment would be a legal contract (whatever the precedent is in that jurisdiction would probably apply). You couldn't do something that's against your contract on the way to work on your first day, for example, and claim that it didn't count because it was before office hours.
The answer to your examples is that the conversion from date to datetime sometimes is ill-defined and you shouldn't assume that this can be properly done.
Legally, employment usually has a well defined start date and end date - and it often simply doesn't have a well defined start datetime and an end datetime, you might as well assume that it's undefined unless/until a particular situation forces you to get a court ruling for that.
Time is so messy, and that messiness becomes apparent when the yes/no, true/false world of computers tries to interpret things.
The blog posts brings up a lot of good points about time zones changing, and the comments make even better points about people moving across time zones. Something that confounds me occasionally is the concept of "local human time" because there are all sorts of ways that humans tamper with time.
Lawmakers, for example, that are required to pass certain laws by a particular date will sometimes unplug clocks in the legislative chambers to stop the legal passage of time while negotiations continue. You end up in a situation where, on paper the next day or week, 134 laws were negotiated, voted on, ratified, re-voted, passed, and signed all at exactly $date:23:59:59. A physical impossibility, but a legal fact.
Or, as I explore the more interesting corners of America more, there are entire towns and regions that ignore their official time zone and every house, business, church, pharmacy, etc... is on a more convenient time for the locals. The only place you see the official time is at the post office.
People are messy. Time is messy. People * time = a complete mess.
> Lawmakers, for example, that are required to pass certain laws by a particular date will sometimes unplug clocks in the legislative chambers to stop the legal passage of time while negotiations continue. You end up in a situation where, on paper the next day or week, 134 laws were negotiated, voted on, ratified, re-voted, passed, and signed all at exactly $date:23:59:59. A physical impossibility, but a legal fact.
Is this internationally accepted or a USA-only thing? It seems like fraud to me.
I don't know about that particular description, but it kind of makes sense - two bills passed on 27th March parliament session are passed on the same "business day" even if that day gets long and one of them was voted on five minutes before midnight and the other was voted on five minutes past midnight; and if there are some mandated legal delays (e.g. you have x days to before they'll be in force or something) then both bills will be treated as if they were passed on the same date.
This also matches common usage - if I tell you what I did on a friday night, it'll include both things before and after midnight.
There are also parallels in banking where business days don't align with calendar days, and you may have (depending on regulations and agreements) either a "long friday" or "long monday" where an action that's physically performed on a sunday will be treated with an effective date of friday or monday respectively; or possibly events after the closure of a business day may be legally treated as happened in the day after.
Offtopic: One time the Cardinals of the Catholic Church couldn't come to an agreement over the next Pope. After a few months of that the Holy Roman Emperor or some such had workmen remove the roof and locked them inside. A day and a half later, new Pope!
> entire towns and regions that ignore their official time zone and every house, business, church, pharmacy, etc... is on a more convenient time for the locals.
Fascinating, and I've never heard of such a thing. Are these towns near a time zone line, that find it more convenient to be in the time zone of a nearby large city on the other side?
I did a full switch to Postgres like 2 years ago, and a decent chunk of the decision was `timestamp with timezone` saved me a huge amount of headaches working on multinational services
Use timestamp with tz, drop Unix timestamps and use ISO8601 DateTime format across the application ezpz never look back
Unfortunately `timestamp with time zone` is misleading and crippled.
When you store something as timestamptz, postgres converts it to UTC and "loses" the timezone part.
The only difference between timestamptz and timestamp is that when postgres is returning the timestamptz to you, it converts it back to your local time zone defined by SET TIME ZONE (and not the time zone it was originally stored in)
So basically if you store a timestamptz, you cannot convert it back to the local time, as the local time is never even stored.
I personally had to add a second `timezone` column to my table to store the timezone of the date.
I wouldn't go so far as to say the timestamp types are broken, just confusingly named. `timestamp with time zone` signifies an absolute point in time; `timestamp without time zone` signifies a timestamp relative to some unspecified time zone (which you must store separately, as you point out). The builtin functions universally adhere to these semantics.
E.g., when you do store the timezone separately, use `timestamp without time zone`: `time AT TIME ZONE timezone` [1] only does the right thing (i.e., interpreting `time` as relative to `timezone`, and producing an absolute time corresponding to it) if `time` is `without time zone`. (If `time` is `with time zone`, it produces the local time corresponding to the absolute time `time`, which is mathematically exactly the opposite of what you want.)
I think PG will exhibit the problems that skeet was referring to because PG stores the UTC time and not the local time. If someone makes a change to the timezone rules then the times your columns are referring to will stay the same in UTC time which might not be what you want.
"For timestamp with time zone, the internally stored value is always in UTC (Universal Coordinated Time, traditionally known as Greenwich Mean Time, GMT). An input value that has an explicit time zone specified is converted to UTC using the appropriate offset for that time zone. If no time zone is stated in the input string, then it is assumed to be in the time zone indicated by the system's timezone parameter, and is converted to UTC using the offset for the timezone zone."
'timestamp with timezone' is kind of a gotcha. i guess it combines two things into one type that are logically one type but it also might mislead someone into believing the type is something else.
timstamptz is fine for historical data and certain kinds of “this will (need to )happen at this time” situations, but as others have said it just converts to/from UTC based on your session time zone - this makes it inadequate for calendaring.
For calendaring or other applications where time zone’s shifting offsets can cause issues you need to store the UTC time along with the timezone and then do the conversion on read.
Additionally, you have to be careful with the Postgres JDBC driver. When you store or load to a timestamp column, it compares the JVM local time zone with Postgres' session time zone and translates appropriately. Even when you have a test that makes sure that you get back the same timestamp that you put into it, it might be the wrong timestamp if you use psql to look at it.
Storing UTC (or rather TAI) is a silver bullet for "system" times - things that need to happen on a regular schedule, where we care how much time has passed between one instant and another, or things where we want to record at what instant something happened, and correlate system events with each other.
Indeed it doesn't solve the problem of handling user-inputted "human" times correctly. But that is a much rarer case than needing to handle "system" times. Many - probably most - applications never need to handle a "human" time at all.
I prefer TIA over UTC and wish it was widely used.
Leap seconds mean the same UTC time can happen twice if we fall back a second, or a UTC time may never happen when we skip ahead a second. Leap seconds also mean that epoch milliseconds derived from UTC do not represent milliseconds between the timestamp and Jan 1 1970 unless the conversion is aware of all leap seconds. Leap seconds are prescribed every six months with six month notice. There are many time keeping devices that are not updated as often as UTC leap seconds are introduced.
I'm pretty happy with ISO-8601, but dates after the year 10,000 will not sort lexicographical. A 64 bit signed int storing milliseconds since Jan 1 1970 covers 29225733 B.C to 29229672 A.D
Honestly, I think that leap seconds were simply a mistake. We could have phase-locked UTC to UT1R via frequency changes instead of via phase changes and much of that hassle would have been avoided.
UT1R is a time of day measurement that is based on making astronomical observations to establish the Earth's angular velocity and phase very precisely with respect to TAI. Leap seconds are created from time to time to keep the offset between UTC and UT1R to less than a half-second.
In effect, UTC is slaved to UT1R via a PLL that is only capable of making phase jumps. Instead, we could have slaved UTC to UT1R via a PLL that only ever made frequency changes. There would be no phase jumps (leap seconds), just very subtle adjustments in clock frequency. Those adjustments are fine enough that the majority of users don't care. The remaining users were already using TAI anyway.
>There are many time keeping devices that are not updated as often as UTC leap seconds are introduced.
Isn't this an argument against using TAI in certain applications though? i.e. if you're designing a system which relies on non-leapsecond-updated devices to be in sync with devices that are capable of being updated, you should always design as such to accommodate the former rather than the latter?
The united states will experience this soon. California and Washington are independently seeking to end daylight saving time. There is no America/Portland or America/Seattle so Washingtonians and Oregonians are using America/Los_Angeles. Unless Washington, California, and Oregon end Daylight savings on the same schedule we'll have to add new id's and users will have to change their configuration, and we'll still have issues described in the link.
The distinction between different kinds of time is really pretty key to having a clear understanding.
Civil time is different from atomic time and different from sidereal time or solar time.
Civil time is how people, businesses, and governments organize and plan their activities.
Atomic time is monotonic, physical, and "more objective" / less dependent on legislatures :)
Sidereal time is about the orientation of Earth relative to stars. It's really important if you're an astronomer.
UTC is a civil time standard based closely on TAI, an atomic time standard, except it gets corrected to be within 1 second of UT1, a sidereal time standard. It is basically _the_ civil time standard and it is a little compromise to make a civil time that advances like atomic time but also does not desync from sidereal time.
Different administrative regions use offsets from UTC to determine their local civil time.
If you're writing an application where people plan future activities and you really want to "get things right / not surprise users", you probably need to store times in the appropriate civil time standard, make it apparent _which_ civil time standard is canonical per activity if people are being coordinated across administrative regions that do not synchronize their standards, and ensure that your application can find out about planned changes to civil time in any of the administrative regions of interest.
Funny you should say that, here's an excerpt from the article:
> And then someone will calmly quote this passage in response, quietly pleased with themselves that the initial commenter was rude and certainly didn’t read the post at all. Then a third person will chime in on the thread saying the author was playing you all like a fiddle anyway, and the real problem is that the post was way too long to start with.
It's funny that it predicts my comment as well, touché.
Readit News
Events generally need to be locked to _something_ - whether that is UTC or a local time zone depends on the application.
The iCalendar standard (https://tools.ietf.org/html/rfc5545) generally gets this right.
I would not be remotely perturbed if my phone had a pop up when I stepped off the plane asking me if I still wanted to wake up at 7AM local or would prefer to wake up at 10AM UTC.
I would be greatly perturbed if it assumed the latter and I missed my meeting, all because I forgot to set a timezone when I originally inserted it a month prior.
In that specific case, it woke me up according to local time, which is what I expected. But what if I had crossed the time zone boundary less than an hour before I wanted to be woken up?
It’s my calendar, why would I set it to events in a way that’s not relative to my time reference?
This is something we (startup insurance company) have thought about a lot actually. Since the certificates we issue are relevant to a particular jurisdiction, if the document states e.g. "23:59:59", it means the "wall clock" time in that jurisdiction - whatever point-in-time our DB contains isn't really that relevant.
So the likely problematic situ is if we've got a policy end date/time more than a year in advance, then the country changes their TZ offsets, we need to make sure our point-in-time records get updated (and then of course the duration of the policy changes). It's a bit of a pain in a system built around immutable events!
On a kinda related note, we also took the decision to clearly define that our start/end date-times have a resolution of one second and are inclusive. So if a policy starts at 00:00:00 and ends at 23:59:59, that's the full day, all the way up to midnight. It also means then it's important that we render the full time (incl seconds) on our docs.
If you had a policy for the calendar year 2016 would it not have covered 31 December 2016, 23:59:60 then?
https://www.timeanddate.com/time/leap-seconds-background.htm...
valid_from: 2019-01-01T00:00:00+x
valid_until: 2019-01-02T00:00:00+x
Even 23:59:59.9999999 would still be < valid_until without any special tricks.
Deleted Comment
Settings - General - Use device time zone
If you disable this, you'll keep everything pinned to your preferred timezone.
But I'm pretty sure a better approach is to select the timezone of the event. If it is at 10am in Germany, why not tell your calendar about this? Sure, this is an extra step, but it is part of the event's parameters (as pointed out in the OP).
Deleted Comment
I think python3's datetime has something like what you're pointing at -- objects are either timezone-aware or not. My complaint probably has to do with trying to hide this distinction from the user, when it would be more helpful to make it clear.
The upshot is that if I travel and change my Mac's clock to local time, all of my events get screwed up. The first time this happened I nearly had a heart attack because I have years of history in my calendar. So I always leave my Mac's clock set to my home time zone and do the conversion in my head.
Deleted Comment
Deleted Comment
It's also very useful that you can set the left margin (in the web app) to show two different time zones in a "ruler" format. So even if your overseas appointments for later in the week are displayed in terms of your current timezone, a quick glance across will confirm what their "local" time will be once you're on the ground.
Sort of a summarization of most of the ideas here is:
* for clear instants like a system log UTC makes sense
* for times in the past (far enough in the past that you know your current TZ rules are correct) UTC makes sense.
* for the immediate past (near enough where your rules might not be correct) you might want to store zone as well.
For all cases of times in the past, remember that you're trying to record an instant. An exact unambiguous point in time that is the same irrespective of who is looking at it or where they are. For this UTC makes sense - people who see that instant converted to their local timezone are noting what their clocks would have shown at that instant, but everyone who will ever see it is always referencing the same instant.
FUTURE times are very different. There are times at which you want to reference a future instant, at which point you can just use UTC, but most often what you really have is "this is what I expect to see on my wall clock when this thing happens". That is a very different beast, because nobody knows what the timezone rules or geopolitical situation will be when that thing does happen.
You need to recognize the use cases where what you mean is " I expect to see XX:YY:ZZ on my wall clock when this happens" and just record that information as is, including as much information as you can about that wall clock - possibly which timezone it (currently) uses, where it is (in case the timezone itself changes) and then convert to an instant at the last possible moment, or keep updating your instant based on changing rules.
We allowed users to define schedules which would control light, temperature, co2, irrigation, etc for greenhouses. Those schedules would load into on premise controllers and run for weeks or months.
They might be built by a user in one timezone and deployed to multiple facilities in different timezones. They often ran across DST boundaries, and some users wanted them to follow "wall clock time" while others wanted to ignore DST to match the behavior of legacy control systems.
In the particular case of employment I'd assume there was as implicit time as well, because employment would be a legal contract (whatever the precedent is in that jurisdiction would probably apply). You couldn't do something that's against your contract on the way to work on your first day, for example, and claim that it didn't count because it was before office hours.
Legally, employment usually has a well defined start date and end date - and it often simply doesn't have a well defined start datetime and an end datetime, you might as well assume that it's undefined unless/until a particular situation forces you to get a court ruling for that.
The blog posts brings up a lot of good points about time zones changing, and the comments make even better points about people moving across time zones. Something that confounds me occasionally is the concept of "local human time" because there are all sorts of ways that humans tamper with time.
Lawmakers, for example, that are required to pass certain laws by a particular date will sometimes unplug clocks in the legislative chambers to stop the legal passage of time while negotiations continue. You end up in a situation where, on paper the next day or week, 134 laws were negotiated, voted on, ratified, re-voted, passed, and signed all at exactly $date:23:59:59. A physical impossibility, but a legal fact.
Or, as I explore the more interesting corners of America more, there are entire towns and regions that ignore their official time zone and every house, business, church, pharmacy, etc... is on a more convenient time for the locals. The only place you see the official time is at the post office.
People are messy. Time is messy. People * time = a complete mess.
Is this internationally accepted or a USA-only thing? It seems like fraud to me.
This also matches common usage - if I tell you what I did on a friday night, it'll include both things before and after midnight.
There are also parallels in banking where business days don't align with calendar days, and you may have (depending on regulations and agreements) either a "long friday" or "long monday" where an action that's physically performed on a sunday will be treated with an effective date of friday or monday respectively; or possibly events after the closure of a business day may be legally treated as happened in the day after.
They are really different things.
Offtopic: One time the Cardinals of the Catholic Church couldn't come to an agreement over the next Pope. After a few months of that the Holy Roman Emperor or some such had workmen remove the roof and locked them inside. A day and a half later, new Pope!
Someone could be born before you, yet you have an earlier birthdate than them.
Fascinating, and I've never heard of such a thing. Are these towns near a time zone line, that find it more convenient to be in the time zone of a nearby large city on the other side?
I've seen both, and neither.
Sometimes it's it's because they're in a deep valley and the sun rises much later than the rest of the zone they're in.
Use timestamp with tz, drop Unix timestamps and use ISO8601 DateTime format across the application ezpz never look back
When you store something as timestamptz, postgres converts it to UTC and "loses" the timezone part.
The only difference between timestamptz and timestamp is that when postgres is returning the timestamptz to you, it converts it back to your local time zone defined by SET TIME ZONE (and not the time zone it was originally stored in)
So basically if you store a timestamptz, you cannot convert it back to the local time, as the local time is never even stored.
I personally had to add a second `timezone` column to my table to store the timezone of the date.
E.g., when you do store the timezone separately, use `timestamp without time zone`: `time AT TIME ZONE timezone` [1] only does the right thing (i.e., interpreting `time` as relative to `timezone`, and producing an absolute time corresponding to it) if `time` is `without time zone`. (If `time` is `with time zone`, it produces the local time corresponding to the absolute time `time`, which is mathematically exactly the opposite of what you want.)
[1] https://www.postgresql.org/docs/current/functions-datetime.h...
https://www.postgresql.org/docs/9.1/datatype-datetime.html
"For timestamp with time zone, the internally stored value is always in UTC (Universal Coordinated Time, traditionally known as Greenwich Mean Time, GMT). An input value that has an explicit time zone specified is converted to UTC using the appropriate offset for that time zone. If no time zone is stated in the input string, then it is assumed to be in the time zone indicated by the system's timezone parameter, and is converted to UTC using the offset for the timezone zone."
'timestamp with timezone' is kind of a gotcha. i guess it combines two things into one type that are logically one type but it also might mislead someone into believing the type is something else.
For calendaring or other applications where time zone’s shifting offsets can cause issues you need to store the UTC time along with the timezone and then do the conversion on read.
Indeed it doesn't solve the problem of handling user-inputted "human" times correctly. But that is a much rarer case than needing to handle "system" times. Many - probably most - applications never need to handle a "human" time at all.
Leap seconds mean the same UTC time can happen twice if we fall back a second, or a UTC time may never happen when we skip ahead a second. Leap seconds also mean that epoch milliseconds derived from UTC do not represent milliseconds between the timestamp and Jan 1 1970 unless the conversion is aware of all leap seconds. Leap seconds are prescribed every six months with six month notice. There are many time keeping devices that are not updated as often as UTC leap seconds are introduced.
I'm pretty happy with ISO-8601, but dates after the year 10,000 will not sort lexicographical. A 64 bit signed int storing milliseconds since Jan 1 1970 covers 29225733 B.C to 29229672 A.D
UT1R is a time of day measurement that is based on making astronomical observations to establish the Earth's angular velocity and phase very precisely with respect to TAI. Leap seconds are created from time to time to keep the offset between UTC and UT1R to less than a half-second.
In effect, UTC is slaved to UT1R via a PLL that is only capable of making phase jumps. Instead, we could have slaved UTC to UT1R via a PLL that only ever made frequency changes. There would be no phase jumps (leap seconds), just very subtle adjustments in clock frequency. Those adjustments are fine enough that the majority of users don't care. The remaining users were already using TAI anyway.
Isn't this an argument against using TAI in certain applications though? i.e. if you're designing a system which relies on non-leapsecond-updated devices to be in sync with devices that are capable of being updated, you should always design as such to accommodate the former rather than the latter?
The united states will experience this soon. California and Washington are independently seeking to end daylight saving time. There is no America/Portland or America/Seattle so Washingtonians and Oregonians are using America/Los_Angeles. Unless Washington, California, and Oregon end Daylight savings on the same schedule we'll have to add new id's and users will have to change their configuration, and we'll still have issues described in the link.
Civil time is different from atomic time and different from sidereal time or solar time.
Civil time is how people, businesses, and governments organize and plan their activities.
Atomic time is monotonic, physical, and "more objective" / less dependent on legislatures :)
Sidereal time is about the orientation of Earth relative to stars. It's really important if you're an astronomer.
UTC is a civil time standard based closely on TAI, an atomic time standard, except it gets corrected to be within 1 second of UT1, a sidereal time standard. It is basically _the_ civil time standard and it is a little compromise to make a civil time that advances like atomic time but also does not desync from sidereal time.
Different administrative regions use offsets from UTC to determine their local civil time.
If you're writing an application where people plan future activities and you really want to "get things right / not surprise users", you probably need to store times in the appropriate civil time standard, make it apparent _which_ civil time standard is canonical per activity if people are being coordinated across administrative regions that do not synchronize their standards, and ensure that your application can find out about planned changes to civil time in any of the administrative regions of interest.
https://zachholman.com/talk/utc-is-enough-for-everyone-right
It is more high level but a very good read on the subject.
> And then someone will calmly quote this passage in response, quietly pleased with themselves that the initial commenter was rude and certainly didn’t read the post at all. Then a third person will chime in on the thread saying the author was playing you all like a fiddle anyway, and the real problem is that the post was way too long to start with.
It's funny that it predicts my comment as well, touché.