5 ms·

Recurring meetings cannot be expressed as timestamps (unless you want all the humans to hate you). The recurrence has to be expressed in terms of local time (an

Recurring meetings cannot be expressed as timestamps (unless you want all the humans to hate you). The recurrence has to be expressed in terms of local time (and date/day of week) in some (ideally per-event) timezone.

ithkuil 5y ago
It's fine as long as all the meetings are conventionally expressed in one time zone. If some meetings are created in some US tz, some other meetings in some EU timezones, then when the biyearly DSTgeddon week(s) come, you not only have meetings shifting unexpectedly but you also have conflicts since some meetings changed and others didn't! Such a mess. But it doesn't happen frequently enough for it to be worthwhile fixing/regulating/whatever
- lolinder 5y ago
  > If some meetings are created in some US tz, some other meetings in some EU timezones, then when the biyearly DSTgeddon week(s) come, you not only have meetings shifting unexpectedly but you also have conflicts since some meetings changed and others didn't! But this is a problem in the real world, not a software problem. Choosing to use UTC when that's not how the business actually thinks about schedules will lead to you just doing your own DST math, which is harder than just storing the correct time zones from the get go.
  - ithkuil 5y ago
    Sure it is a real world problem. And no, I wasn't advocating for UTC which would not work for half a year, instead of causing a few days of minor headaches. It's caused by the fact that different branches of a large corp have genuine situations where some meetings are between local employees and other situations where you invite a mix of distributed people. Thus there is no "natural default" as to which timezone is "correct".
chrismcb 5y ago
Why not? Assuming you mean utc when you say timestamp. You just need to covert it the users timezone before displaying it.
- alecbz 5y ago
  For a repeating meeting I think the construct you want is actually a datetime, generally. E.g., a weekly meeting is not a meeting that happens on one particular timestamp and then repeats every 24*7 hours. If you hit daylight savings time, you want a 9am meeting to still be on the "new" 9am, not shift to 10am or 8am.

ithkuil 5y ago

It's fine as long as all the meetings are conventionally expressed in one time zone. If some meetings are created in some US tz, some other meetings in some EU timezones, then when the biyearly DSTgeddon week(s) come, you not only have meetings shifting unexpectedly but you also have conflicts since some meetings changed and others didn't! Such a mess. But it doesn't happen frequently enough for it to be worthwhile fixing/regulating/whatever

lolinder 5y ago
> If some meetings are created in some US tz, some other meetings in some EU timezones, then when the biyearly DSTgeddon week(s) come, you not only have meetings shifting unexpectedly but you also have conflicts since some meetings changed and others didn't! But this is a problem in the real world, not a software problem. Choosing to use UTC when that's not how the business actually thinks about schedules will lead to you just doing your own DST math, which is harder than just storing the correct time zones from the get go.
- ithkuil 5y ago
  Sure it is a real world problem. And no, I wasn't advocating for UTC which would not work for half a year, instead of causing a few days of minor headaches. It's caused by the fact that different branches of a large corp have genuine situations where some meetings are between local employees and other situations where you invite a mix of distributed people. Thus there is no "natural default" as to which timezone is "correct".

chrismcb 5y ago

Why not? Assuming you mean utc when you say timestamp. You just need to covert it the users timezone before displaying it.

alecbz 5y ago
For a repeating meeting I think the construct you want is actually a datetime, generally. E.g., a weekly meeting is not a meeting that happens on one particular timestamp and then repeats every 24*7 hours. If you hit daylight savings time, you want a 9am meeting to still be on the "new" 9am, not shift to 10am or 8am.