Hacker News Reader

Comment by 14u2c | Hacker News Reader

What is the issue with that use case? I am a firm believer in storing all time as GMT / UTC in the database layer then converting to local time in the UI layer according to the current user's attributes.

In this situation, when the user enters "8 am on Saturday", they would do so in their local time, it would be converted to GMT before inserting, and again back into local time when that record is viewed in the UI.

View on HN

I suspect (as someone who doesn't write code that cares and therefore hasn't thought much about it) that it's easy to write... let's say naive code that occasionally results in the user entering "8AM this Saturday" and getting 7AM that Saturday because their country observes a DST switch.

Don’t time switches usually occur on Sunday morning specifically because things are rarely scheduled on Sunday mornings (even church starts at 10 or 11AM)?

I think you're missing the point of the message you're responding to, perhaps because they accidentally chose an example that is unlikely to cross a DST change.

What I think they're saying is that if you don't take DST into account at all, you might decide that "8am on Tuesday" will be using the current offset from UTC rather than the offset as it will be on the given day, whether by that logic or by adding multiples of 24 hours in similar cases.

I feel like nobody has given a very clear answer, here. For future events, a UTC timestamp is insufficient because it doesn't take into account timezone-db changes (like the US now going to permanent DST). And you can't fix it after the fact, because even if you stored the offset, that's not sufficient to know whether someone is in the US (which is changing) or just somewhere sharing that offset on that date.

If I already have something scheduled for 9am in the US on some day in December, on systems like yours, where you're assuming UTC is fine and complete, it's now going to be an hour off. It's not even the first time the US has been affected - there were lots of issues with alarm clocks going off early/late and similar after they changed the dates of DST.

The ideal way is to store a timezone (like "America/New_York") for the event and the time in local time. If you have efficiency concerns, you can also store a redundant UTC copy but you'll need to remember to keep updating it. Also, you may need to store the user/entity for the event, so you can handle the user themselves changing their location (if you're running an internet alarm clock system).

Be warned, btw, that "GMT" is now ambiguous; Windows 95 called "BST" (British Summer Time) "GMT Summer Time" and it seems to have stuck and so "GMT" means current UK time for many. (Language evolves, even when technical users don't want it to.)

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.

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.

"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.

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.

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

UTC is great for timestamps, but for time periods that are meant to be used locally your code will get complicated if you store them as UTC. For example, functions like is_monday?(date) and length_of_period(date, date) are very simply mathematical operations if the time is local. But if you stored dates as UTC then you need a translation and take into account the edge condition that the date occurs during a DST switch.

It's not sufficient in many cases, especially when scheduling things that you expect to happen at a specific local time.

https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...

Reply on news.ycombinator.com