Hacker News Reader

Comment by rlpb | Hacker News Reader

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.

The iCalendar standard (https://tools.ietf.org/html/rfc5545) generally gets this right.

View on HN

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.

In Gmail (and Inbox, RIP), the 12:30am "Snooze" action assumes "tomorrow" means 8am the same day. I'm not sure what time the switch-over becomes "8am the next day". I think around 4 or 5am. Once I learned that's what happens, it became just as useful as "later today".

I use both quite a bit. I'd definitely rather not be asked every time - especially since I work at night and do most of my email management in that timeframe

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?

For the question of crossing a time zone boundary while using local time, I'd say the answer is obviously to go off the moment local time passes the alarm time.

Going the other way is a more fun problem, but a few hours of debouncing is fine for anyone moving at suborbital speeds.

If I'm going from my personal experience when travelling across timezones, I generally set my phone to the local time, check it about 5 times, call the front desk and request a wake-up call, and set the bedside alarm. All three have failed me at one time or another and I'm a little paranoid about sleeping through meetings!

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?

I agree with this as you've stated it, but there's a difference with a personal event, like an alarm, and a calendar event.

For instance, say there's an 1pm CT meeting every Tuesday for a remote team. When I head to the East Coast for a week, that _should_ mean 2pm ET, but if the assumption is "1pm when I'm there", since the "there" has changed if my calendar doesn't adjust accordingly I'm going to be an hour early to the meeting.

This has happened to me numerous times. I set up an appointment in Outlook assuming I'll be there remotely via webconference and then end up having to travel there in person. I've been bitten enough times to double-check the timezone now, but that was a hard-earned lesson that most calendars tend to use the timezone the appointment was created in unless explicitly told otherwise.

I'm a swede watching a lot of NFL and college games. Often the only thing I see are American times and need to input them easily in my calendar. Then I'm more interested in inputing "1pm EST" into my calendar and let the calendar figure out when to alert me of the game.

Because you may have an appointment at the place you are going, not the place where you are now.

For ref, this is the relevant bit: https://tools.ietf.org/html/rfc5545#section-3.3.5

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

A question to both parent of this and this specifically.

How would you deal with the current EU situation? They have recently voted to stop yearly transitions to summer time. But there must still be a timezone assigned to an event.

Are you assigning timezones (in the certificates themselves) as the timezones of a particular geographic location,, rather than as time offsets?

On the certificates, we'd state e.g. "this policy runs from 27th March 2019 at 16:52:12 (GMT) to 3rd April 2019 at 17:52:12 (BST)" for a 168-hour (~7 day) policy.

Logically, we think of it as the "wall clock" time, plus the location ("Europe/London" - we don't operate outside the UK yet), plus the local zone (BST/GMT) to handle ambiguity when clocks go back.

Practically, right now the start/end date-times are stored using a Postgres timestamp with no timezone. As we've never issued an individual policy of more than 28 days' duration or more than 7 days in advance, we've never actually had to deal with any situation where the point-in-time is no longer correct. And this case is not likely to happen without a decent amount of notice.

We're very much in favour of abolishing seasonal transitions though - causes lots of confusion.

> And this case is not likely to happen without a decent amount of notice.

In the jurisdictions you care about. Last-minute timezone changes do happen, and the main time zone database has been updated retroactively in the past. It's actually possible that a timezone change has even been enacted retroactively (thanks to countries that like doing very last-minute DST starts).

Yeah indeed - for now we're fortunate that it's not something we need to worry about actually handling perfectly. It's more something we like to think about at this point.

One day we will need to deal with it and conversations like these are super helpful to support that.

If a time is designated as "local" it is most flexible to store the location in a way that will handle the dynamism. e.g. I would not record a time as "16:00 BST" but rather "16:00 Europe/London" and use the olson timezone db to resolve it to BST or GMT downstream.

You should definitely use geographic timezone like America/Los_Angeles instead of just offset. Offset actually isn't a real timezone it is just an offset. Timezone usually means a lookup table of what offset it has at what time and that can also change due to different laws at different time. So I assume the moment EU countries will change the rules there will be one more row for each timezone that will say "from this time the offset is such and such". That means it is also important to use the right timezone in the sense that even though Bratislava/SK and Prague/CZ have the same rules (DST time and offsets) at the moment they can change in different ways after the DST is removed (as whether to use winter or summer time afterwards is in jurisdiction of each country I think).

I agree. In the only project I worked on where time was really important I stored a triple (original datetime, UTC timestamp, original time zone). I used UTC to globally sort events and sent the original datetime back to clients for display.

On the other side, sometimes we don't know where an event happens. Think of GPS trackers close to a border which is also a timezone border. This is a more complex problem which requires at least a model of country borders and maybe roads.

Finally, on some systems I'm using as a user, they have some EU timezones but not even all the major countries. It doesn't matter now but it will. I expect they'll add the missing timezones and make us confirm where we are.

That doesn't solve the problem. Suppose Massachusetts were to decide to move from the Eastern to the Atlantic time zone and New York were to decide to remain in the Eastern time zone. The time zone you would need for people in Massachusetts would be America/Boston, not America/New_York--which doesn't exist now.

Representing future times correctly is very hard, especially because time zone changes (including creation of new ones!) aren't always announced years in advance.

None of these tricks will help if I’m insuring myself for international travel. Only the trip to and from the airport is in the time zone of the policy.

Any incidents along the way or after that are going to need an interpretation relative to UTC.

Thanks for mentioning this. I came across this page which discusses the theory and practice of timezone databases. https://data.iana.org/time-zones/theory.html

> 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.

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...

Claims are lodged by humans. I doubt any human would report they had a loss at 23:59:60 hehe!

> I doubt any human

Never trust user input though, of course :P

What if the loss was caused by and at the leap second? e.g. imagine a self-driving car that ignored input during the leap second and crashed into a lane divider? You may have proof that the accident occurred at exactly 23:59:60.

What if the car is flying through the air aside a suspension bridge at 23:59:59 and :60, and crashes into the water a second or two later? Has the loss occurred the moment the impact with terrain becomes inevitable, or not until impact?

Exactly. It's usually best to specify end times exclusively, and not just for leap seconds; it's easier to program in general. If your clock has sub-second granularity, then you can end up with a time value like 23:59:59.123. Which will require some truncation before it can be compared like t ≤ 23:59:59. If you use exclusive end times, you can do the comparison directly; 2016-12-31 23:59:59.123 < 2017-01-01 00:00:00. The key is that now we have an end date-time that actually specifies a true instant in time, and isn't an interval in and of itself.

For that very reason, for start/end policy times, we store them aligned to the second - no fractional seconds allowed. There'd be no legal basis for that anyway.

Obviously for actual timestamps - e.g. created at/updated at times - we do store a point-in-time with fractional seconds.

Very fair point.

From an operational perspective, if there was an incident in the second between 23:59:60 and midnight, it would of course be covered - irrespective of what's in any system, written on any doc, displayed in the app, etc.

We don't worry too much about leap seconds - particularly as very few people are even likely to realise it was a factor, and the national Motor Insurance Database (MID) does not support them.

The MID doesn't even allow us to specify timezones, so every year we sell around 20-30 one-hour car insurance policies which appear to run for 1 second - displaying the same start and end time on police computers etc. (Due to the clocks going back from BST to GMT.)

From a legal perspective, the time written on the policy doc is inclusive - we can't just decide that we want it to be exclusive because it suits our purposes.

> From a legal perspective, the time written on the policy doc is inclusive - we can't just decide that we want it to be exclusive because it suits our purposes.

Well, apparently it's not if it's understood that it covers leap seconds as well. With regard to the internal modeling, I always go for half-open intervals, where the open side depends on the data being modeled, they have much nicer mathematical properties than closed intervals.

Why not:

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.

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.

Google Calendar does let you set the time zone in the 'More options' view, FWIW. I use it occasionally.

I know. But I want no time zone. When I plan my Germany trip next week I want to see the 10 am meeting there at 10 regardless of where I am.

It should operate like a good old paper calendar.

Google Calendar is built around notifications and coordination, which both require an agreed upon "actual" time.

The feature set you're looking for sounds more like an "agenda" to me.

I think what he wants is that the software defers asking for a time zone until the item relates to two users who have different timezone.

And that if the event arrives without having touched users in different timezones, then the software should infer that the event's timezone is the local timezone of all users at that point in time and space.

What I would like is to to be able to set my "local time schedule" and be able to do it in advance. So for example if I am traveling next week I can indicate that my local time will change.

This is great not only for me but also for other people trying to schedule events in my calendar.

With Gmail picking up flight and hotel confirmations this could even be mostly automatic.

Its not that you want no time zone, you want to mark the appointment as "local" time. That could be useful, though I expect it would create as many problems as it solves.

The explicit timezone is crucial for conference calls that cross timezones. That is at least half of the appointments on my calendar (I coordinate projects between the US, Europe and Asia).

For international phone meetings this is good but for travel it’s really bad.

I still disagree. I also travel a lot, and I set the meetings in the timezone where the meeting is. It's not a paper calendar.

Right. When I travel I usually have a combination of physical meetings in local time and phone calls back home or spanning multiple time zones. I do mess up sometimes but I’m not sure how much you can automate.

> It should operate like a good old paper calendar.

In that case, you enter a recurring 10 am conference call every Monday, and the moment you move timezones you miss the call.

The problem really is (as mentioned in this thread) that the user's intent is not known.

There are two use cases: one is for meetings with participants in different timezones. Gcal does this well. There other use case is travel. For this the current system is not very good.

Well, you know the timezone: it's of wherever in Germany the meeting will take place.

I think the problem is the display: since you know you'll be in Germany from date X to Y, you should be able to configure the presentation timezone for those days (which would also show you those meetings in the local time when you'll have to make them).

Most people have more events that happen at a particular instant but different local times (e.g. phone calls between people in different timezones) than events that happen at a fixed local time but different instants. When I'm planning my trip to Germany I certainly don't want it showing all my calls at the wrong time.

The iCalendar standard does actually support that, but perhaps Google Calendar's UI does not. I suspect it does work internally, because it interoperates with iCalendar fairly well.

The standard calls it a "floating" DATE-TIME:

"The recipient of an iCalendar object with a property value consisting of a local time, without any relative time zone information, SHOULD interpret the value as being fixed to whatever time zone the "ATTENDEE" is in at any given moment."

There's a workaround, which is that you can set a time zone for an event in GCal.

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.

On my Palm Pilot there was a “floating” time zone that behaved like this. But I can’t find this feature in any modern app. Outlook doesn’t have it either.

Apple's calendar has it on macOS, but not on iOS... (it's annoying how mobile everything always has to be so neutered)

And yet iOS calendar is also more powerful in that you can set different time zones on the start and end of a single event, which macOS calendar will show but not let you edit.

Paper calendar/planners don't have this problem. That's why I still use them.

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).

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.

And what if the event is an airplane flight that starts and ends in different time zones?

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.

I use Apple's Calendar and had misremembered how it handled time zones. It handles them the same way.

Reply on news.ycombinator.com