|
|
|
|
|
by thih9
524 days ago
|
|
> make it the 24hr (...) period relative to the current timezone What if the event gets shared - should the dates still be relative to the timezone of the creator? Or to the most popular timezone? Or should they be different for everyone? Or something else? What if the event is recurring and the creator travels between the occurrences, should the times change? When should the times be updated? Should all events change, or only the future events, or only the closest one? What if a participant uses multiple devices in multiple timezones at the same time? …etc. Perhaps there are ways to solve all these and more; my point is that in the context of calendars even adding a flag can get complex fast. |
|
Is that really that bad? This doesn't sound like a reason not to do this. Because the worst case scenario is that... we end up with the current implementation...
Here's some shitty pseudocode. You could do this and store as UTC time but I think storing with timezone makes the point clearer. All day events are marked as starting at the beginning of a day and ending at the end of a day. That being from our Date structure, which holds Month, Day of month, hour, minute, second, whatever precision, as well as special things like when the beginning of the day is and when the end of the day is. Here the function start_of_day() and end_of_day replaces whatever input values for {hour, minute, second, ...} with the appropriate values and attributes _sod and _eod are those values.This assumed you stored events as a time with a timezone. If you stored events in UTC you'd need different logic. I mean time is messy, but either way we're moving stuff around. I mean we're just _displaying_ offsets when moving timezones, right? Because it would be wild to update all events every time we moved timezones, right? So we have to do some logic to take the date and display it relative to its time
With a timezone invariant flag all we're doing is saying
No, IT IS AN ALL DAY EVENT They don't, IT IS AN ALL DAY EVENT Doesn't matter, IT IS AN ALL DAY EVENTI'll raise you a question
Think about that answer.It is really not a hard problem. Because you are storing the events in some database. Moving timezones is then a conversion process. The invariant flag is just saying "keep the time relative to the day."
I don't disagree, but I'm failing to see where this specific issue is an actual problem.