8 ms·

This kind of thing is why it's important to store user-specified future dates as local time + IANA zone name. If a user wants a calendar event at 9am, they pro

This kind of thing is why it's important to store user-specified future dates as local time + IANA zone name. If a user wants a calendar event at 9am, they probably still mean 9am after accounting for time zone or DST changes. Storing dates as UTC is appropriate for dates in the past, or future dates that a user will never expect to happen at a certain wall-clock time. (An IANA zone name is something like America/New_York, and not EST or UTC-05:00)

MobiusHorizons 4y ago
It’s one heuristic, but you can’t know what they want, the problem is underspecified. It’s reasonably likely they could want a reminder to watch a game that is being broadcast from a different time zone, or call a friend in a different country.
- toast0 4y ago
  The user interface can be akward, but you can ask them for the timezone of the event. If it's for a live event in another place, they would ideally put in the local time in the other place and the timezone there. Or if it's a fixed time, not to be moved by DST changes anywhere, they could specify it in UTC. It's also a good idea to calculate and save the offset when editing. Then, if the offset changes later, you can notify the user. Hey, this appointment is affected by DST change, when do you want it to be?
  - lifthrasiir 4y ago
    Yes, many tz-related difficulties indeed arise from the future uncertainty and UX complexity to deal with that uncertainty. A conscious decision would be required and can't be easily delegated to someone else.
  - macintux 4y ago
    I can’t even get employees at the company where I work to understand and communicate EDT instead of EST. I don’t think calendaring tools are going to have much success asking people what timezone they want.
    - yorwba 4y ago
      The stock calendar app on my Android phone (running LineageOS, so not sure how "stock" it really is) has a quite prominent time zone field when setting the time for an event, and I do use it quite a lot.
    - delecti 4y ago
      I've mostly given up being pedantic about the difference between PT, PDT, and PST. Most people mean "PT" when talking about the time that work meetings are scheduled, but they say "PST" basically year-round, despite it being PDT more often than PST.
      - kragen 4y ago
        It's not a pedantic difference; if you calculate the time as PST when it's PDT or vice versa you'll be an hour off. Holding a meeting an hour early or attending it an hour late can have serious consequences.
        vxNsr 4y ago
        OP is calling it pedantic because most people mean PT. When someone says 9am they mean 9am regardless of the timezone, they’ll add the timezone if they’re talking with someone from a different timezone but still 99% of the time they mean 9am in their own timezone so if they’re in a region that observes dst even if they said pst they really meant pdt and you’re being pedantic by correcting them.
        delecti 4y ago
        I agree that it's an important difference, but being insistent about it is excessive because functionally those kind of mistakes just don't happen when scheduling meetings in Outlook, which is the context where it matters. Most of my work meetings only involve people in the same city, so there's no confusion there, and thus no scheduling problems. And 99% of the rest of my meetings are with people in Europe, and the relative difference between PST and CET is the same as the relative difference between PDT and CEST (though I do have to remind people twice a year that the two time zones change to/from DST a week or two apart).
  - AndreasHae 4y ago
    A lot of this could be solved by inferring the time zone by location of the appointment. If you know the event occurs in a specific place at a specific time, you almost certainly want it to be the standard time zone of that place. If that place uses DST, I couldn’t think of any reason to ignore it and opt for standard time regardless. Bonus: geopolitics change country lines, and that affects time zones as well. When the time zone at the appointment location changes due to border conflicts, you can get the new time zone without having to change anything.
    - toast0 4y ago
      That works if you know the location of the appointment. But if you're going to a bar to watch a televised game with friends, the location in the appointment is probably the bar, but the timezone is wherever the game is held. If you're going to have a conference call and you have a shared calendar system, great everybody should agree; if all the participants have separate calendar systems, maybe you discuss the time to have the call and each enter it in your local time, which works fine until someone's government adjusts local time on short notice. Having separate appointments sounds fragile, but have you had a good experience with cross domain calendaring? I certainly haven't. Never mind, if you had a fully booked schedule collaborating across timezones and someone's government adjusts local time, now you've got a mess.
  - jkaplowitz 4y ago
    There should also be a way to say "my current local time, whatever that may be", such as for events reflecting a personal daily routine for exercise, medicines, etc. This should adjust accordingly as the person changes time zone instead of staying at a fixed UTC offset.
    - toast0 4y ago
      that's "floating time" and is definitely a valid option too, although for uses with multiple devices, now they've all got to agree on which timezone the user is currently subject to if you want a consistent experience.
- foepys 4y ago
  But this is one more reason to save the timezone and stop calculating on current data? Save the time and timezone of the event in the other country, so literally the time it starts not the calculated local time. Unless the other country decides to switch timezones, well then you are screwed.
  - tsimionescu 4y ago
    That assumes you know what timezone the user intended. If I read somewhere that some football match in Chile is happening on November 1st at 1 o'clock, I may well put in a reminder for November 1st at 1 o'clock, without specifying a timezone or location. The calendar/reminder app would of course be unable to notify me that Chile's time for November 1st has changed, since I never told it anything about Chile.
    - mason55 4y ago
      What exactly do you expect it to do? Asking the user for the location of the event for time zone purposes might be confusing but there’s no better option.
      - tsimionescu 4y ago
        The more common option is not to do that, and accept that in the rare cases of a timezone change, there's nothing you can do from software. Either way, the only completely fool-proof way to make sure you never return the wrong time is to ask not for a timezone, but for GPS coordinates, and preferably some extra cultural information - since the timezone of a particular location may change completely, and that change may only be recognized by certain entities. For example, when Russia annexed Crimeea, they could have changed the timezone (I believe they didn't, but they could have), but more nationalistic Ukrainians in Crimeea would have probably not recognized the timezone change. So, if someone had set an event for some time in the future and chose Ukraine's timezone, they may not have gotten the right reminder if the event was public (so presumably forced by Russian authorities to respect the new timezone), since you couldn't know they meant to watch something in Crimeea. To be clear, I'm arguing it's not worth trying to solve this problem in a fool-proof way in software, not that I expect software to help in situations like the above.
- nisegami 4y ago
  Then isn't the appropriate solution to store the time for that time zone?
vxNsr 4y ago
Can you give a few examples of what you mean by this?
zeroonetwothree 4y ago
Agree that this is a good default, but this doesn’t solve everything. For example a meeting between people in two time zones. Typically that’s handled by picking one time zone as the primary one, but that’s always not ideal. Also some events aren’t related to human activity and you would rather not make that adjustment. It can be tricky to know which is which.
grog454 4y ago
It's more a demonstration around why changing your wall clocks in unpredictable ways (and to a lesser extent, changing them at all) is a bad idea.
- hilbert42 4y ago
  Well console yourself with the fact that the current timezone arrangement is much better than the 19th C. system where every town had its own separate timezone. When railways were introduced a multitude of local timezones made railway timetables impossible, this then led to the present system.
TJSomething 4y ago
I like keeping the offset and the zone name. Then, if there's a discrepancy, I can ask the user what to do about affected events.
xani_ 4y ago
> If a user wants a calendar event at 9am, they probably still mean 9am after accounting for time zone or DST changes. ...9am of their timezone or 9am of other participants time zone ? Countries also share a timezone, what happens when they stop ? what if you store time in CEST but the date CEST changes into CET is different in different countries ?
firecall 4y ago
This is why I insist on calendar invites for all my meetings! People easily forget that others in a meeting loop are in different time zones. Not so bad in parts Europe or the UK, but for those of us in countries with multiple TZs like the US and Australia, it’s a persistent problem! Especially for those junior members who are new to the group video conferencing game! Conveying TimeZones in software is also a UX issue I’ve found! People don’t really understand LOL
Falkon1313 4y ago
Better still, just store dates as ISO-8601 standard YYYY-MM-DD format. Mucking about with timezones at all inevitably introduces bugs when you're just talking about dates. Of course, times sometimes do need timezones. But calendar dates (like Christmas, or your birthday) almost never do and having things automagically do adjustments based on that and give the wrong results is just a pain. That's one thing I don't like about many standard libraries. They'll have a DateTime object that does all kinds of automagic stuff for you (or against you), but no concept of just a date itself. Many bugs occur between 2300 and 0100 due to that (and sometimes between 1100 and 1300 because people try to compensate for the buggy adjustments by setting the unwanted time component to noon). Another problem arises when the server's timezone is set to X, the database's timezone is Y, the software's timezone is Z, and one user's entering data in timezone A while another is reading it in timezone B - and all of the software parts along the way are each trying to automagically adjust it. A good reason we should just all switch to UTC and drop the idea of timezones entirely.
Ndymium 4y ago
Storing datetimes as UTC is not enough for even past dates for all situations. If you need to know what local time an event happened in the past and there's more than one location your user may have resided in, you need to have stored the local time as well, since there's no reliable target you could convert that UTC to.

MobiusHorizons 4y ago

It’s one heuristic, but you can’t know what they want, the problem is underspecified. It’s reasonably likely they could want a reminder to watch a game that is being broadcast from a different time zone, or call a friend in a different country.

toast0 4y ago
The user interface can be akward, but you can ask them for the timezone of the event. If it's for a live event in another place, they would ideally put in the local time in the other place and the timezone there. Or if it's a fixed time, not to be moved by DST changes anywhere, they could specify it in UTC. It's also a good idea to calculate and save the offset when editing. Then, if the offset changes later, you can notify the user. Hey, this appointment is affected by DST change, when do you want it to be?
- lifthrasiir 4y ago
  Yes, many tz-related difficulties indeed arise from the future uncertainty and UX complexity to deal with that uncertainty. A conscious decision would be required and can't be easily delegated to someone else.
- macintux 4y ago
  I can’t even get employees at the company where I work to understand and communicate EDT instead of EST. I don’t think calendaring tools are going to have much success asking people what timezone they want.
  - yorwba 4y ago
    The stock calendar app on my Android phone (running LineageOS, so not sure how "stock" it really is) has a quite prominent time zone field when setting the time for an event, and I do use it quite a lot.
  - delecti 4y ago
    I've mostly given up being pedantic about the difference between PT, PDT, and PST. Most people mean "PT" when talking about the time that work meetings are scheduled, but they say "PST" basically year-round, despite it being PDT more often than PST.
    - kragen 4y ago
      It's not a pedantic difference; if you calculate the time as PST when it's PDT or vice versa you'll be an hour off. Holding a meeting an hour early or attending it an hour late can have serious consequences.
      - vxNsr 4y ago
        OP is calling it pedantic because most people mean PT. When someone says 9am they mean 9am regardless of the timezone, they’ll add the timezone if they’re talking with someone from a different timezone but still 99% of the time they mean 9am in their own timezone so if they’re in a region that observes dst even if they said pst they really meant pdt and you’re being pedantic by correcting them.
      - delecti 4y ago
        I agree that it's an important difference, but being insistent about it is excessive because functionally those kind of mistakes just don't happen when scheduling meetings in Outlook, which is the context where it matters. Most of my work meetings only involve people in the same city, so there's no confusion there, and thus no scheduling problems. And 99% of the rest of my meetings are with people in Europe, and the relative difference between PST and CET is the same as the relative difference between PDT and CEST (though I do have to remind people twice a year that the two time zones change to/from DST a week or two apart).
- AndreasHae 4y ago
  A lot of this could be solved by inferring the time zone by location of the appointment. If you know the event occurs in a specific place at a specific time, you almost certainly want it to be the standard time zone of that place. If that place uses DST, I couldn’t think of any reason to ignore it and opt for standard time regardless. Bonus: geopolitics change country lines, and that affects time zones as well. When the time zone at the appointment location changes due to border conflicts, you can get the new time zone without having to change anything.
  - toast0 4y ago
    That works if you know the location of the appointment. But if you're going to a bar to watch a televised game with friends, the location in the appointment is probably the bar, but the timezone is wherever the game is held. If you're going to have a conference call and you have a shared calendar system, great everybody should agree; if all the participants have separate calendar systems, maybe you discuss the time to have the call and each enter it in your local time, which works fine until someone's government adjusts local time on short notice. Having separate appointments sounds fragile, but have you had a good experience with cross domain calendaring? I certainly haven't. Never mind, if you had a fully booked schedule collaborating across timezones and someone's government adjusts local time, now you've got a mess.
- jkaplowitz 4y ago
  There should also be a way to say "my current local time, whatever that may be", such as for events reflecting a personal daily routine for exercise, medicines, etc. This should adjust accordingly as the person changes time zone instead of staying at a fixed UTC offset.
  - toast0 4y ago
    that's "floating time" and is definitely a valid option too, although for uses with multiple devices, now they've all got to agree on which timezone the user is currently subject to if you want a consistent experience.
foepys 4y ago
But this is one more reason to save the timezone and stop calculating on current data? Save the time and timezone of the event in the other country, so literally the time it starts not the calculated local time. Unless the other country decides to switch timezones, well then you are screwed.
- tsimionescu 4y ago
  That assumes you know what timezone the user intended. If I read somewhere that some football match in Chile is happening on November 1st at 1 o'clock, I may well put in a reminder for November 1st at 1 o'clock, without specifying a timezone or location. The calendar/reminder app would of course be unable to notify me that Chile's time for November 1st has changed, since I never told it anything about Chile.
  - mason55 4y ago
    What exactly do you expect it to do? Asking the user for the location of the event for time zone purposes might be confusing but there’s no better option.
    - tsimionescu 4y ago
      The more common option is not to do that, and accept that in the rare cases of a timezone change, there's nothing you can do from software. Either way, the only completely fool-proof way to make sure you never return the wrong time is to ask not for a timezone, but for GPS coordinates, and preferably some extra cultural information - since the timezone of a particular location may change completely, and that change may only be recognized by certain entities. For example, when Russia annexed Crimeea, they could have changed the timezone (I believe they didn't, but they could have), but more nationalistic Ukrainians in Crimeea would have probably not recognized the timezone change. So, if someone had set an event for some time in the future and chose Ukraine's timezone, they may not have gotten the right reminder if the event was public (so presumably forced by Russian authorities to respect the new timezone), since you couldn't know they meant to watch something in Crimeea. To be clear, I'm arguing it's not worth trying to solve this problem in a fool-proof way in software, not that I expect software to help in situations like the above.
nisegami 4y ago
Then isn't the appropriate solution to store the time for that time zone?

vxNsr 4y ago

Can you give a few examples of what you mean by this?

zeroonetwothree 4y ago

Agree that this is a good default, but this doesn’t solve everything. For example a meeting between people in two time zones. Typically that’s handled by picking one time zone as the primary one, but that’s always not ideal. Also some events aren’t related to human activity and you would rather not make that adjustment. It can be tricky to know which is which.

grog454 4y ago

It's more a demonstration around why changing your wall clocks in unpredictable ways (and to a lesser extent, changing them at all) is a bad idea.

hilbert42 4y ago
Well console yourself with the fact that the current timezone arrangement is much better than the 19th C. system where every town had its own separate timezone. When railways were introduced a multitude of local timezones made railway timetables impossible, this then led to the present system.

TJSomething 4y ago

I like keeping the offset and the zone name. Then, if there's a discrepancy, I can ask the user what to do about affected events.

xani_ 4y ago

> If a user wants a calendar event at 9am, they probably still mean 9am after accounting for time zone or DST changes. ...9am of their timezone or 9am of other participants time zone ? Countries also share a timezone, what happens when they stop ? what if you store time in CEST but the date CEST changes into CET is different in different countries ?

firecall 4y ago

This is why I insist on calendar invites for all my meetings! People easily forget that others in a meeting loop are in different time zones. Not so bad in parts Europe or the UK, but for those of us in countries with multiple TZs like the US and Australia, it’s a persistent problem! Especially for those junior members who are new to the group video conferencing game! Conveying TimeZones in software is also a UX issue I’ve found! People don’t really understand LOL

Falkon1313 4y ago

Better still, just store dates as ISO-8601 standard YYYY-MM-DD format. Mucking about with timezones at all inevitably introduces bugs when you're just talking about dates. Of course, times sometimes do need timezones. But calendar dates (like Christmas, or your birthday) almost never do and having things automagically do adjustments based on that and give the wrong results is just a pain. That's one thing I don't like about many standard libraries. They'll have a DateTime object that does all kinds of automagic stuff for you (or against you), but no concept of just a date itself. Many bugs occur between 2300 and 0100 due to that (and sometimes between 1100 and 1300 because people try to compensate for the buggy adjustments by setting the unwanted time component to noon). Another problem arises when the server's timezone is set to X, the database's timezone is Y, the software's timezone is Z, and one user's entering data in timezone A while another is reading it in timezone B - and all of the software parts along the way are each trying to automagically adjust it. A good reason we should just all switch to UTC and drop the idea of timezones entirely.

Ndymium 4y ago

Storing datetimes as UTC is not enough for even past dates for all situations. If you need to know what local time an event happened in the past and there's more than one location your user may have resided in, you need to have stored the local time as well, since there's no reliable target you could convert that UTC to.