[kzemek]

Except when that's an alarm clock time, and the user takes a trip on Friday that moves him -4h worth of timezones.

Or if their local legislature suddenly decides to cancel the DST change that was supposed to happen Friday night.

[noitpmeder]

I generally agree there is a problem here... but anyone storing repeatable alarm times in the future as absolute time points in the future is going to be in for issues regardless.

[ghusbands]

Yes, and that's what the post they were responding to was suggesting and they were pointing out was broken.

[8n4vidtmkvmk]

ya.. storing time is hard. in this case since its an alarm, presumably in local time, it should be saved in local time i think. if it's a log/record of something happening then utc is good. if its a date without a time, then dont use a full timestamp because any offsets might change the say if you leave it at 00:00.

[grey_earthling]

"Friday 08:00 at my location" is not necessarily the same as "Friday 08:00 London time" is not necessarily the same as "Friday 08:00 UTC+1", but it's very difficult to ask the user which of these they mean in a way they'll understand.

I (very occasionally) work on some software that schedules web content to appear at a certain future time. We had a bug once where during summer, an editor had scheduled an item to appear a few weeks in the future, at 09:00. We displayed this time back to them in our current local timezone (but presumably stored it as UTC), and it looked correct. When that scheduled date came, our timezone had reverted to winter time, and the content appeared an hour late.

We should have displayed the scheduled time in "what the local timezone would be at the scheduled time", or stored the time with a timezone expressed as a location rather than a UTC offset.