5 ms·

I think it's more in the spirit of the article to say, forget timezones, use UTC millis everywhere. If the server doesn't speak in timezones, then you eliminate

I think it's more in the spirit of the article to say, forget timezones, use UTC millis everywhere. If the server doesn't speak in timezones, then you eliminated all bugs where the server mishandles timezones.

s3m4j 8y ago
In my experience, it's been easier to push UTC time all the way from the db to the user javascript and operate on time then, than trying to manipulate time before sending to the user. YMMV, and it's only web dev.
- taeric 8y ago
  This works for things that have happened. It doesn't work too well for schedules. In those cases, the timezone of the source matters, heavily.
  - majewsky 8y ago
    For example, a task that occurs "daily at 15:00" does not always happen every 24 hours. When DST comes into effect, the interval shortens to 23 hours once.
    - falcolas 8y ago
      Or, at "2:30 am" in the continental US can occur twice in a day, or not at all. Of course, even that isn't guaranteed, if you're in AZ. Even "notify me in exactly 24 hours has its own complications. Leap seconds will screw up your day (as will the vague request of "exactly 24 hours"). Corner cases, the bane of simplicity everywhere.
  - s3m4j 8y ago
    To this day, knock on wood, I have had success at voluntarily avoiding those issues ^^ (aside from school assignements)
- marcosdumay 8y ago
  There are many kinds of data that get saved as time. For some, yes, it's better to add and remove the TZ at the interface. For some the TZ carries meaning by itself, and it must be stored and keep constant everywhere. For some the TZ carries meaning, but the time must be converted for display. Know your data, and most of your problems get easy.
  - everybodyknows 8y ago
    Yes, that's the crucial distinction -- whether the TZ, with its coarse encoding of the geography of origin, carries significance to the consumer of the data.
SamuelAdams 8y ago
I agree - UTC is the way to go. The point of the example was to illustrate how simple could be detrimental to a significant portion of your userbase. How about another example? You're building an android application. Let's pretend there's an API in the latest version of Android that reduces a dozen lines of code down to one function call - ShinyNewMethod(). You can use that ShinyNewMethod() call. It's certainly simpler. But the vast majority of android devices in use are not running the latest OS. So the NewShinyMethod(), while being simple, will cause your app to not work for them. Hopefully the framework designers figured a way to have this auto-reverse engineer for older devices, but that's not always a guarantee.
- AstralStorm 8y ago
  This results in funny things like android support library.
jstimpfle 8y ago
But no, what about UTC leap seconds? Use TAI! :)))
masklinn 8y ago
> I think it's more in the spirit of the article to say, forget timezones, use UTC millis everywhere. If the server doesn't speak in timezones, then you eliminated all bugs where the server mishandles timezones. That's a flagrant example of "simple and wholly incorrect". If you don't store timezones, your future dates will eventually turn out incorrect when timezone offsets change e.g. create a meeting at 9AM local, store as UTC, country decides to not follow DST that year bam your reminder will ping an hour early or late. Or a day off when the country decides to jump across the international date line (https://en.wikipedia.org/wiki/International_Date_Line#Samoan_Islands_and_Tokelau_(1892_and_2011) https://en.wikipedia.org/wiki/International_Date_Line#Samoan...).
- dredmorbius 8y ago
  The UTC example allows the user to translate output using localised tools. The solution isn't incorrect, it is modular.
  - masklinn 8y ago
    > The UTC example allows the user to translate output using localised tools. So you provide an alarm clock which is works as neither a clock nor an alarm. > The solution isn't incorrect, it is modular. It's either not correct or not a solution, either way it's useless. I also like how proponents of "simplicity at all cost" apparently assume/assert the composition of two systems is no more complex than either, and that there is no additional complexity to the composition layer.
- y4mi 8y ago
  most applications don't need to schedule events into the future though and its a smart strategy if all you need to worry about is the past
  - masklinn 8y ago
    For very specific cases? Sure, but none of the comments talking about UTC everywhere cares to specify this rather important bit. Unless restrictions are specified I will assume we're talking about the general case, and for the general case it's just plain wrong.

s3m4j 8y ago

In my experience, it's been easier to push UTC time all the way from the db to the user javascript and operate on time then, than trying to manipulate time before sending to the user. YMMV, and it's only web dev.

taeric 8y ago
This works for things that have happened. It doesn't work too well for schedules. In those cases, the timezone of the source matters, heavily.
- majewsky 8y ago
  For example, a task that occurs "daily at 15:00" does not always happen every 24 hours. When DST comes into effect, the interval shortens to 23 hours once.
  - falcolas 8y ago
    Or, at "2:30 am" in the continental US can occur twice in a day, or not at all. Of course, even that isn't guaranteed, if you're in AZ. Even "notify me in exactly 24 hours has its own complications. Leap seconds will screw up your day (as will the vague request of "exactly 24 hours"). Corner cases, the bane of simplicity everywhere.
- s3m4j 8y ago
  To this day, knock on wood, I have had success at voluntarily avoiding those issues ^^ (aside from school assignements)
marcosdumay 8y ago
There are many kinds of data that get saved as time. For some, yes, it's better to add and remove the TZ at the interface. For some the TZ carries meaning by itself, and it must be stored and keep constant everywhere. For some the TZ carries meaning, but the time must be converted for display. Know your data, and most of your problems get easy.
- everybodyknows 8y ago
  Yes, that's the crucial distinction -- whether the TZ, with its coarse encoding of the geography of origin, carries significance to the consumer of the data.

SamuelAdams 8y ago

I agree - UTC is the way to go. The point of the example was to illustrate how simple could be detrimental to a significant portion of your userbase. How about another example? You're building an android application. Let's pretend there's an API in the latest version of Android that reduces a dozen lines of code down to one function call - ShinyNewMethod(). You can use that ShinyNewMethod() call. It's certainly simpler. But the vast majority of android devices in use are not running the latest OS. So the NewShinyMethod(), while being simple, will cause your app to not work for them. Hopefully the framework designers figured a way to have this auto-reverse engineer for older devices, but that's not always a guarantee.

AstralStorm 8y ago
This results in funny things like android support library.

jstimpfle 8y ago

But no, what about UTC leap seconds? Use TAI! :)))

masklinn 8y ago

> I think it's more in the spirit of the article to say, forget timezones, use UTC millis everywhere. If the server doesn't speak in timezones, then you eliminated all bugs where the server mishandles timezones. That's a flagrant example of "simple and wholly incorrect". If you don't store timezones, your future dates will eventually turn out incorrect when timezone offsets change e.g. create a meeting at 9AM local, store as UTC, country decides to not follow DST that year bam your reminder will ping an hour early or late. Or a day off when the country decides to jump across the international date line (https://en.wikipedia.org/wiki/International_Date_Line#Samoan_Islands_and_Tokelau_(1892_and_2011) https://en.wikipedia.org/wiki/International_Date_Line#Samoan...).

dredmorbius 8y ago
The UTC example allows the user to translate output using localised tools. The solution isn't incorrect, it is modular.
- masklinn 8y ago
  > The UTC example allows the user to translate output using localised tools. So you provide an alarm clock which is works as neither a clock nor an alarm. > The solution isn't incorrect, it is modular. It's either not correct or not a solution, either way it's useless. I also like how proponents of "simplicity at all cost" apparently assume/assert the composition of two systems is no more complex than either, and that there is no additional complexity to the composition layer.
y4mi 8y ago
most applications don't need to schedule events into the future though and its a smart strategy if all you need to worry about is the past
- masklinn 8y ago
  For very specific cases? Sure, but none of the comments talking about UTC everywhere cares to specify this rather important bit. Unless restrictions are specified I will assume we're talking about the general case, and for the general case it's just plain wrong.