3 ms·

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 decid

• 8n4vidtmkvmk 5y ago
  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 5y ago
    "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.
• noitpmeder 5y ago
  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 5y ago
    Yes, and that's what the post they were responding to was suggesting and they were pointing out was broken.