> I think I can say this on behalf of most developers who have ever had to fix DST errors in their code: Thank fucking god.
I think it just means for all American developers it's _more_ likely they'll introduce bugs if they cater to an international audience and there's still countries with DST.
DST has always been a good way to get Devs to think about the timezone database. If people start relying on offsets more that's not a net good thing, until the entire world is done with DST.
I was on on a US Navy ship, and the main display clock in combat control had two times - Zulu and a local time adjustable by an hour offset. This was obviously terrible... when we docked off India we had no way to set the correct time!
India and a few ocean side countries in that region are at UTC+5:30. Nepal (which is not near any ocean but is adjacent to India) is at UTC+5:45.
There is no end to time zone related oddities, including the way DST and standard time switching happen in the U.S./Canada vs. how it happens in Europe.
South Australia and the Northern Territory in Australia are on UTC+10:30 as well. We also do daylight savings per state. So, although NSW and QLD are both on the same UTC+11:00 timezone for the summer months NSW is 1 hour ahead because it has DST but QLD does not!
Agreed. I noticed that a lot of websites only really started supporting Unicode properly once emojis started becoming popular. When Unicode was "just" accented characters, a lot of English speaking devs didn't bother and happily lived in an ASCII-only world.
Major programming languages think it's perfectly sufficient to let everyone sound like Yoda.
To be fair, I snoozed through sentence structure in English class. It wasn't until I was trying to conjugate verbs in another language that it became concrete for me and I had to understand it.
If you have a DSL that retains order of the arguments, you're gonna have a bad time. Full Yoda mode engaged. If you have one that allows named interpolation, you'll sound less dumb. If you have one that allows conjugation, better yet. But at the end of the day there are languages that use different adjectives or number systems[1] based on the object or direct object of a sentence, and so you might not be able to substitute "apples" "people" and "files" interchangeably into the same template, even if you can do things like differentiate "There is 1 file in this directory." from "There are 3 files in this directory." without having to build a Cartesian product of all combinations.
1) In Japanese there are different words for counting different things, but Arabic numerals are acceptable, so you can leave it to the reader to determine which word to use. I don't know that this is true in all other languages with discrete counting systems.
Last time I worked with a product that had translations, we very quickly centered on needing to just translate the whole phrase. And we were only doing a couple "boring" European languages.
GMT is great for client/server interactions. But users have a habit of wanting things to happen at "8 am on Saturday" and GMT is lousy for things like that.
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.
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.)
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.
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.
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.
I think it just means for all American developers it's _more_ likely they'll introduce bugs if they cater to an international audience and there's still countries with DST.
DST has always been a good way to get Devs to think about the timezone database. If people start relying on offsets more that's not a net good thing, until the entire world is done with DST.