After a heckuva lotta research and reading we determined that we needed to store the scheduled meeting time using two values; the local datetime and the desired timezone eg.
scheduledAt: 2018-05-29T23:41:16.167 scheduledAtZone: Europe/London
Everything else in the system like created, updated, ended data is stored using UTC and transposed on the client using the user's stored time zone preference. eg.
createdAt: 2018-05-29T22:41:16.167Z
The application server your app is running on of course needs to run on Etc/UTC but with that in place (so far...touch wood) we haven't had a problem in our usage.
When I say "becomes a lot of fun" what I actually mean is that this observation lets us understand very quickly that the problem is not generally solvable. One way or another, somebody's 9 o'clock meeting is going to suddenly take place at 10. Having accepted that, we can push through the idealism and start working actual solutions like the one you described - have the user attach the regularly scheduled meeting time specifically to the UK or to the US.
very funny things happen when there is a shared physical resource e.g. a booked meeting room, and you have a bunch of people schedule meetings with different reference time zones.
ah, and if you think this creates havoc only for a the few weeks while the TZs are out of sync, remember that in the southern hemisphere DST is applied in "reverse"
In my country the train stops for one hour at the spring DST change and just waits for time to pass to account for the "missing" hour and not mess up the schedules by arriving one hour earlier.
It's also interesting that since this doesn't happen frequently enough it's usually hard to develop a good way to get out of it.
"The timezone you have used to define this booking has been altered, and the booking cannot be updated due to unavailability of the resource XXXX. Please choose a new time for this booking."
Heheh, exactly. We're currently debating how best to implement this since this one is more a UI issue than a UTC/Time issue.
For example if the user wants to schedule a call at 2pm New York time (UTC-4) we need to show them the consequences of dialling a participant in the UK (UTC+1) and even more so someone in Sydney (UTC+10).
If you use your ZonedDateTime classes carefully in your code (or equivalents if not using Java) then your app does take care of the DST changes. You can then show the user the scheduled time for not just the person making the creating the event but for every participant - ultimately the user has to decide what compromise to make when scheduling events across time zones and DST changes.
My side doesn't observe DST. The other side does. The border keeps different Summer and Winter hours.
Trying to figure out when I need to leave to make sure I get to the border during its open hours to get through, and then when I need to leave (in local time on the other side) to get back through during the open hours is an extremely tedious problem.
Worst part is crossing the border is just me driving South. My longitude doesn't really change.
Time is an illusion.
Lunchtime doubly so.
— Douglas AdamsIn local time would be “my meeting starts at xxx”. Leap seconds schould not be involved there, and neither the system time. The users aren’t going to be glad you’re doing that.
How does that work when the same local datetime happens twice during a DST switch, or when a local datetime is skipped during the other side of a DST switch?
Specifically, future events which aren't tied to a geographical location, and ones which are. And in the latter case, determining which single location it should be pegged to.
A: "We'll have a global phone call to discuss this crisis in exactly X hours from now."
B: "The keynote for the convention in CityName will occur at 3pm."
I.e Does "Last 2 days" indicate: A. Last 48 hours? B. Yesterday + Today up to now C. Yesterday + the day before.
This is a difficult subject.
Recurrence is especially tough to model in a database.
Often the user means "same day of the week, four or five weeks from now".
Gets it right for you. If I mean today, I say today. This is especially true when I'm talking to a computer.
Sometimes we need to use non-human language to communicate intent correctly to a computer, but we shouldn't let that redefine perfectly good and well established human language.
Your definition has the same issue that mine does, just with sunrise being the time around which the meaning of tomorrow is unclear. How high does the sun have to be before "today" becomes defined and the meaning of "noon tomorrow" shifts by 24 hours? If I wake up before sunrise, does tonight refer to now or to after the next sunset?
There's a certain amount of ambiguity inherent to the English language.
I think using midnight as the anchor for the today/tomorrow distinction is a lot less confusing and ambiguous than having today/tomorrow not tied to the current date.
Just print the date and time.
/folks up north
For the case you propose, I read it as a "meeting" planned at a point in the future. In this case storing the start of the meeting as a bare timestamp is inappropriate design. What really should be encoded is the set of rules for identifying the proper timestamp. There was an existing standard mentioned for that which I'd use as a starting point if designing or implementing (if I chose their design) such a system.
Form follows function. If the concept of “10 AM on Saturday” is important to your users, model the software in line with that domain knowledge. All problems are bounded by context, and knowing the boundaries makes designs simplier and easier to manage.
The tricky thing to realize is that this is not a datetime. This is more of a contract/condition saying "when localtime will be at this value" or better yet "when localtime will have exceeded this value for the first time" because you know someone will put a date on a leap second or missing DST hour at one point.
My son’s friend in school was born on February 29. We could go through the time pedantry and claim that she is 1 year old (she is 6), or pick an arbritrary moment in time (say March 1, except for leap year) and get on with the party.
If you’re plotting a satellite course, the details matter, but many, if not most use cases require consistency over precision.
Indeed, your son's friend's age is an ambiguous notion, Hence the need of a more precise contract than a simple date.
It's unfortunate how few libraries exist to handle abstract datetime constructs, and how frequently programming environments screw this up. The only one I know of that doesn't mince concepts is Java 8 Time [1], where points-on-timeline timestamps are clearly separate from human-centric calendrical concepts like Time-of-Day (LocalTime) and Month-Day without a year, so there's an appropriate datatype to model lots of common use-cases of date math.
[1] https://docs.oracle.com/javase/8/docs/api/java/time/package-...
There is still a caveat, though. Locations can change timezone. Sometimes they do it fairly often (like every few years). You need access to a good timezone/location database that is updated regularly :-(
When we were doing this project, I was really surprised at how often we got problems. If you sell things all over the world (there are golf courses in ridiculous places), the probability that you will stumble into an anomaly is surprisingly high. Alas, this project was not a commercial success as the margins on tee times are quite small (and the tee time services you have to work with are often quite badly written). But it was quite fun to work on.
I hate time.
Good example: you, user A, are in a TZ that switches biannually - at one point in the year you lose an hour, at another you experience an hour twice. Now, another user B is also in one of these whacko places and creates a meeting (while experiencing an hour for the second time) or what-have-you for a future time where user A goes through their local groundhog hour. You have a backend server that, for legacy reasons, simply truncates TZ and goes with its own local TZ. That server is in another TZ that has an identity crisis. JS is doing dumb stuff that only JS could do. Does your brain hurt yet? I'm pretty sure that this engineer can now perceive four dimensions.
He didn't receive a bug report until we migrated to UTC. UTC made things worse, somehow. As it turns out UTC is only good for when you care about a machine doing something at some time, or when working relationally.
Store TZ (ideally location, an offset is not a TZ) along your dates. When presenting them include that information, as well as relational ("3 days, 4 hours ago at 00h15 in WA").
Time is nuts.
This sounds exactly like a line out of some Douglas Adams book. Which is perfectly fine as long as no one booking meetings on that app has read any of his books.
For example, if you store time in TAI then you'll have to recompute all other future times as leap seconds are announced.
Some Google database systems rely on tight time synchronization to order update events, so they had to have a global monotonic clock.
Computing future times in TAI from user inputs in wall clock time is fraught, so I guess you can't store TAI in those cases.
For a calendar app, since users want to deal in wall clock time, you have to store time with timezone and with leap seconds (so UTC + time zone). And you have to store timezone, not offset to UTC -- timezones can change.
At least internally, however, dealing in TAI can be helpful[0].
Also, IIRC there's a proposal to redefine UTC as without leap seconds[1]... That scares me. Users really need wall clock time.
The continued existence of TAI was questioned in a 2007 letter from the BIPM to the ITU-R which stated "In the case of a redefinition of UTC without leap seconds, the CCTF would consider discussing the possibility of suppressing TAI, as it would remain parallel to the continuous UTC."[16]
Why would getting rid of leap seconds from UTC be a problem for that?
The reason there are leap seconds is nothing to do with wall clock time, it's because some people feel the time ought to be intimately connected to the Earth's rotation, but the Earth doesn't oblige by rotating steadily.
In my view the people demanding this relationship be maintained ought to take responsibility for fixing it from their side. Speed up or slow down the Earth. Can't? Too bad then, but don't expect us to keep fiddling with the clocks.
You are probably thinking of sun transit time, "solar noon", the moment in each day when the sun appears to be "highest" in the sky. This varies of course by position on the Earth, it's how people set "noon" when they didn't need to agree with anybody more than a horse ride's distance away what the time was. So, let's say at least 200 years or more ago.
Do you know when solar noon is where you live now? No? Because it's irrelevant. Huge numbers of people live in places where the solar noon changes by an entire hour twice a year for no sensible reason. Does this cause a huge problem? No, there's a slightly elevated rate of road accidents and things like that, but nothing major. A few seconds per decade is _nothing_.
"it is very difficult to predict — especially the future."
Of course, calendar events in icalendar have the tzdata stored along with them, in theory, so they should never change unless your client updates them. Which leads to its own world of fun.
For the past and present, UTC is fine, and a source timezone if necessary. To track the exact instant when something happened to me, just storing UTC is fine. If I want to know what where the hands on my clock were when that happened, you also store which clock I was using separately (timezone), but this is optional and doesn't prevent accuracy.
For future times, relating to humans, like on a calendar, there's a very important distinction - I want to set appointment when my clock shows a certain time, irrespective of what the timezone rules (Daylight saving time rules can change) are at that point. Here, storing the UTC time for my appointment according to today's rules is a problem - you must simply store what I expect to see on the clock and apply the timezone rules lazily at the last possible minute.
2018-05-26T13:45:21+02:00
Will never change, regardless how many time zone changes you may have. What does change is the method to compute the time difference. So can you say how many days, hours, minutes, seconds ago that was from:
2043-02-12T11:15:16+02:00
You won’t be able to, because then you have to account for leap seconds, etc.
Also “next Tuesday” does have to take into account the time zone as you may need to deal with daylight saving time.
However “next Tuesday” is not a date-time, but a relative difference from where you are now and by pre-calculating you lose information.
Also relevant, in such cases storing the time zone doesn’t help because the user himself might travel and next Tuesday at 7:00 can remain the same, no matter what time zone you’re talking about.
a) "I'll be there in 12 hours", implication being that if there happens to be a DST change, it doesn't matter.
and relative calendar time
b) "I'll meet you 15:00 next monday".
Both of which are valid.
What's interesting is: which of these is most useful in programming, generally? Which should the APIs make easier, or even cater for at all?
I would submit that most applications only care about "physical time"[1], but specifically [b]logging[/b] is actually really interested in calendar time. Fortunately, with logging there's so much volume that you can usually tell pretty easily when there's been a discontinuous time event -- it's a pain in the ass to rebuild timestamps, post hoc, though.
[1] Calender-type application is actually pretty niche IME. Opinion may vary.
Then adapting for local time will screw any schedule not pegged to local time (even for stuff as trivial as following an international event)
Time is hard.
So you really need to store {datetime, timezone_name}.
It gets tricky when you don't know the timezone... For example, you're on a plane with your devices in airplane mode and no wifi connectivity, and you want to create a calendar event in destination time... The UI had better let you specify a TZ, and you'll have to know what it is. Whereas if you want until you land you can just let your devices figure out what TZ you're in and spare you the bother of thinking about it. That's an unlikely edge case, but the UI should really let you input a TZ if you want to. Perhaps the UI should insist on you entering a TZ if you're in airplane mode.
It will respective to the local time though if a state decides to stop honoring DST or changes TZ.
Ah yes, American Atlas: United States Latitudes, Longitudes, Time Changes and Time Zones 5th Edition by Thomas G. Shanks 448 pages.
Covers probably well over 100K locations each with its own history of timekeeping.
The absolute point in time relied on future knowledge that did not yet exist, that invalidated any previous estimate of when it would occur. An external timezone reference (the Olsen DB) must be continually updated and separately referenced
If the timezone changes under my feet the unix timestamp might suddenly not refer to my birtday anymore.
Watching people struggle with this is frustrating.
Also I currently work with frontend and while it is no surprise that JavaScript has messed this up badly [0] it surprised me when I realised that a certain large UI framework had a) messed it up b) didn't realize it and tried to close it down when people tried to help.
[0]: they copied Javas first broken Date handling and suddenly they were stuck with it IIRC.
Edit: heh, double-ninjaed
Of course, if you have a meeting that spans timezones, this is unavoidable. I think the real solution actually lies in how the meeting time is expressed to the user so they don't have misconceptions about it.