3 ms·
The most annoying case is when an event is already scheduled, and the timezone then changes. E.g. it is decided that from now on, DST will end a week later. Wh
by bux93 2y ago
The most annoying case is when an event is already scheduled, and the timezone then changes. E.g. it is decided that from now on, DST will end a week later.
What to do with the events that were scheduled in that week before this change was known? One assumption is that the intent was to schedule it at the same time during the business day (the 9 o'clock meeting, lunch is at 12 etc.); but then you would've been better off storing local time with a location rather than even a timezone, as the (lack of) S in the timezone might not have been intentional.
I'm not saying you shouldn't use UTC though, I'm saying daylight savings is ludicrous and should be gotten rid off.
- afiori 2y agoMy personal taste is to store a day, a time, and a regional timezone (like Europe/Berlin) for calendar-like uses.
- tracker1 2y agoBut even then, you'd need to notify those users who now have that in their own local calendars on the other side of the world... assuming they aren't using an electric attachment with the original TZ. For example, working in a secure environment and putting certain events on a calendar manually on one side or the other.