8 ms·

Stop asking users for their timezone – use per-device settings and JavaScript

96 points by neilk 13y ago

cmadan 13y ago
jstz is a great JS library that we use at my startup for automatic timezone detection http://pellepim.bitbucket.org/jstz/ http://pellepim.bitbucket.org/jstz/
icebraining 13y ago
UTC, not GMT.
- dfc 13y ago
  I had the same reaction. Whenever I read GMT I know instantly that the author is not a big time nut and to take the rest with a grain of salt...
kintamanimatt 13y ago
This pretty much breaks progressive enhancement. If anything, the user's time zone should be first estimated from their IP address with a setting to override it. The client side solution to further refine it should be piled on top of this last, if possible. JavaScript is useful, but nobody should assume it's present. Also, it should be noted which time zone a time is in. A naked date/time is about as useful as saying that you're 3 units away from me. What unit does "unit" represent? shrug
- crazygringo 13y ago
  1) Exactly. This doesn't help at all with server-side rendering of times, which is usually the use-case (times associated with forum comments, etc.). IP address detection is pretty annoying to do (and doesn't help with VPN's etc.), but a quick <script> in the <head> of any page that does an instant "redirect" to put the JavaScript timezone info into a server-side session variable is a functional, albeit hackish, solution. (If you don't have JavaScript enabled, then just serve up UTC times, it's an edge case.) 2) Usually your times are stored server-side in UTC, so you never have to worry about timezones anywhere. It simplifies things a great deal. "Naked" = UTC. You assume that, whenever it's stored, it's already been translated from the user's timezone when the date was initially generated, or else the time it happened on the server was the actual time.
  - kintamanimatt 13y ago
    Sorry, I meant naked date/times that are displayed on a page. It might be that site A gets the user's local time zone correct, but site B, C, and D don't. By displaying the time zone abbreviation next to the displayed time it removes all ambiguity and possibility for error. Also, if it's a time zone abbreviation that's displayed (e.g. EDT) make sure to mark this up properly and fully explain which time zone and country this is for. I can't remember which, but there are some time zones that have the same initialisms. Some don't have initialisms at all, and users from, say, Poland might not know what PDT is either.
    - eksith 13y ago
      This is what we did on a recent project. The times were left at UTC with a hover tooltip (JS with a fallback to title="Coordinated Universal Time") and we used the "timeago" plugin for jQuery http://timeago.yarp.com http://timeago.yarp.com . So far, no complaints.
- trevoro 13y ago
  By your logic I'd be running a WAP site over Gopher to satisfy the progressive enhancement ethos. At a certain point it's absurd to assume javascript isn't there. [1] What brought on this particular use case was a JSON response where all the times were in UTC. I'm not really into forcing a technique on someone when it isn't required. If that's not your use case, then you don't have the problem! [1] http://www.mozilla.org/en-US/firefox/23.0/releasenotes/ http://www.mozilla.org/en-US/firefox/23.0/releasenotes/
  - kintamanimatt 13y ago
    No, that's patently absurd, although I have been known to use w3m while doing work in vim, and I'm super grateful when a site is usable from a text only browser. Screen readers and bots (including search engine spiders) have an easier time with well written HTML. Progressive enhancement is far better for the end user and not all that hard to implement. Some people choose to disable JavaScript, and there are compelling reasons to do this especially if, for example, you're using TBB and want to minimize your attack surface, as has been demonstrated recently. JavaScript isn't evil by any means, and it's really important for creating cool shit, but it should never be required. If I can't use your site with scripts disabled, neither can a lot of other people. Sucks to be them though, right?
    - lucisferre 13y ago
      > it should never be required What a ridiculous statement. Lots of things are "required" if you want certain products to be useful. An XBox is required if I want to play XBox games. Hell you require a web browser just to be able to enjoy the pleasure of checking that "disable javascript" box (though be careful you don't use Mozilla) in the first place (I mean you could use CURL but then you don't actually get to disable javascript). The point is lets stop kidding around about Javascript here, no-javascript guy. > If I can't use your site with scripts disabled, neither can a lot of other people. People who need to disable Javascript are a vanishingly small portion of any potential market, there are many more use cases as far as web apps go where javascript is essential to any decent user experience. Not everything built on web technology is only about content these days. If you don't want to use that technology be my guest, but don't pretend your an important market to people developing on that technology. > Screen readers and bots (including search engine spiders) have an easier time with well written HTML. True but two things. 1) Web applications rarely rely on SEO outside of landing pages and a content strategy neither of which should rely on javascript for obvious reasons. 2) Designing applications for disabilities is extremely hard. Much harder than simply using "well written" HTML. Do you know how hard it is for blind people to play most video games? Again we're talking about interactive applications, not simply content. With content there is no problems but as we already went over the web is not only content now. Edit: One more thought, technically translating the time to the local timezone setting of the browser is "progressively" enhanced. You could always just display UTC time if JS is disabled assuming that was important enough to your users to disable JS (or for bots).
- TazeTSchnitzel 13y ago
  Progressive enhancement of dates is easy. Output UTC, update to local time zone with JS. Simple!
- DigitalTurk 13y ago
  Oh, I hate when website follow your approach. To start, it doesn't work if you use VPNs. Second, it doesn't update when you travel. Here's one example. Even though I'm logged into Google and used Google Maps' 'pinpoint my location' feature, Google Reader is currently emailing me my daily schedule (a feature I enabled recently) in the afternoon. That's also despite my appointments being annotated with timezone information. I call this bad engineering.
- eli 13y ago
  Geolocating the timezone based on IP is so fragile and likely to fail that IMHO it's not nearly worth the time to implement.
  - justincormack 13y ago
    Indeed and will get worse with ipv6 rollout no doubt.
- lvturner 13y ago
  An option to override this is a must, I frequently use VPNs and as a result appear in many different countries through-out the day - It's bad enough with google repeatedly blocking my accounts for suspicious logins, without having to worry about timezone differences too. Also, it'd be nice to ALERT me when my timezone has changed and give me an option to keep the old one, or use what you think my current one is.
- hrktb 13y ago
  In this case progressive enhancement is offering a GMT date or other sensible default, and offer another date after javascript kicks in. Personaly, I think for anything where timezone is relevant, the best move is to always let the user manually enter the timezone he/she wants, or have it match the timezone of the event/service he's looking for, and of course allow for override, so changing timezone has to done client side. I.e. if I am in Germany and search from a flight taking off from Taipei two days from now, I don't care about the departure time from the German timezone. Same thing if I reserve a restaurant in Germany while I am in Taipei, you'll want the german time for the reservation. For something internationally broadcasted showing the UTC time as default and provide a way to adapt to other timezone is OK, as the event has no local anchoring anyway. People can do the calculation for timezones, eventually some opt to not change their phones timezone to keep in sync with other more important schedules, etc. Trying to do 'smart' things seamlessly is often just screwing with the user.
tjoff 13y ago
Fortunately operating systems on laptops and mobile devices all adjust timezones automatically whenever they connect to the internet. My laptop has never changed timezone automatically. And that is a feature in my eyes. How can you assume that just because I'm doing a weekend trip that I want my whole life to be centered around the timezone in that particular place?
- crazygringo 13y ago
  Most people want their clocks to be correct, local time, including their laptop clock. It's a better assumption to make for most people. Of course, it can always be turned off for others, like yourself! :)
  - tjoff 13y ago
    Citation needed. I'd say that a vast minority (that actually cares) wouldn't want the OS to change the timezone behind their back on a laptop. On a phone (which also acts as a wrist watch for most people), yes. Laptop, just no. What OS does this? And how?
    - crazygringo 13y ago
      OSX for sure. "Set time zone automatically using current location". Checkbox inside system preferences. I think it's pretty safe to say most people want their laptop's clock to match their local time, because how is a wrong clock useful? Of course, if you're travelling for business with complicated schedules and meetings in home times, you clearly might have different needs, but most people just want their clocks to be right. And you certainly don't want to keep your original timezone but change the clock setting -- then just everything's wrong! :)
      - tjoff 13y ago
        On my laptop, any time that isn't the current time in my hometown is the wrong time. And it is moronic for the OS to do this change behind my back (I don't know how OS X present this but thankfully Windows 7 doesn't do this madness by default). How do I know that my OS got the time right? (did it perhaps get the time from my VPN location? was the network I connected to badly configured?) Since a laptop isn't connected to the net at all times I also have to consciously be aware of whether I've even been connected yet in this particular time zone.
rustynails 13y ago
If you do localise content, make sure it's what your users want. When it comes to Rotten Tomatoes, I'm glad it asks my location because I prefer US film reviewers to my local film reviewers. If I let Rotten Tomatoes know my time zone, I can't access US reviewers (that I'm aware of).
anigbrowl 13y ago
While we're at it, why (if I'm in the US) do I have to keep selecting my state, town etc., in addition to my zipcode?
- joevandyk 13y ago
  It's less work for the developers, who might have more important things to do?
  - anigbrowl 13y ago
    More important than accommodating the users, aka customers? Hmmm.
- JSadowski 13y ago
  Because zip codes do not equate to cities 1 to 1. Many cities have multiple zip codes, and some zip codes span multiple cities. Zip codes are based on postal routes, cities are not.
  - anigbrowl 13y ago
    Zipcode plus address is usually plenty though. And it's certainly good enough to obviate the tedious selection of the state from a 52-item dropdown menu.
- eric_the_read 13y ago
  ZIP codes can be shared among multiple towns. Quite possibly multiple states, though I can't think of an example offhand.
  - showerst 13y ago
    That's correct; via wiki - For example ZIP code 42223 spans Christian KY and Montgomery TN, and ZIP code 97635 spans Lake OR and Modoc CA. Zip codes are also non-contiguous in some areas, and not bounded-polygons in others which makes them really bad for geo purposes.
taylodl 13y ago
It seems most people resort to storing time in UTC, but this isn't your only option: any fixed time zone will do. If you're in a corporate setting and the majority of your users are in the same time zone as your servers, then it makes sense to use that time zone. There's fewer date conversions that way. For half the year there will be basically no conversions and for the other half it's a 1 hour DST conversion - which many time handling libraries have optimized (I'm in the United States in an area that observes DST for half the year).
- TazeTSchnitzel 13y ago
  >any fixed time zone will do. Theoretically, yes. In practice, you should just use UTC. >If you're in a corporate setting and the majority of your users are in the same time zone as your servers, then it makes sense to use that time zone. No it doesn't. Use UTC. The Internet does not have a time zone. >There's fewer date conversions that way. Your library is probably "converting" the date anyway, UTC or not. >for the other half it's a 1 hour DST conversion - which many time handling libraries have optimized Is it really that slow to convert a date?
- apaprocki 13y ago
  Storing datetimes in fixed timezones that do not observe DST will do (but it is still not recommended), but you can't say any fixed timezone will do. Say you're storing datetimes in EST/EDT and you have a global audience. On the day the US goes back to standard time, how do you know whether 1:30AM in your database is the "first" 1:30AM or the "second" 1:30AM when you need to display the event to someone in Dubai? Are you going to store some extra metadata to indicate whether DST was in effect beside the datetime? Just store UTC.
  - taylodl 13y ago
    A fixed time zone doesn't shift for DST, otherwise it wouldn't be fixed - by definition. All you need is a fixed reference point. There's nothing sacrosanct about UTC.
    - 13y ago
btipling 13y ago
I want to agree, but there are times when you have to ask for timezones, like when you want to collect and present data in discrete time units like days. If a user wants to know how many app installs they have per 'day', you have to know what time the time the day they care about begins and ends before you start dumping data into those time delineated buckets. It's not always the timezone their browser uses. Especially not with agencies that are providing these services for clients that are somewhere else.
jenseng 13y ago
UTC offset is well and good if you are talking about today, but as soon as you start displaying past or future datetimes, DST will bludgeon you over the head. And depending on your app, users might want control over the timezone. When a teacher creates an assignment in canvas-lms, the due date defaults to midnight of the selected day. It would be surprising if it set it to 2am, just because the teacher happened to be traveling when the assignment was created.
- excitom 13y ago
  Exactly. I have run into this problem with event calendars. For example: Schedule a recurring event for 1pm. It happens to be EDT at the moment so you store the event date/time in UTC by adding 5 hours. Then, in days, weeks, or months, we change to EST. The 1pm meeting is now showing at noon. To fix this I run a cron job on the ST/DT boundaries that increments or decrements stored date/times in the event calendar.
amiruci2 13y ago
I looked into getTimezoneOffset when implementing pre-orders here at Gumroad and realized that technically this is incorrect: "Luckily, the browser already knows what timezone the user is currently in, so we can make use of the getTimezoneOffset() function" Getting the timezone offset isn't the same as getting the timezone. Granted that in certain cases having the offset is good enough, but sometimes you need the actual timezone. In my example I needed to know when a merchant wants their pre-order to be released. For that to work predictably I needed to know their exact timezone in order to adjust the time for daylight saving properly. Remember that there are quite a few timezones that are UTC-7 and they can behave differently in regards to daylight saving.
dan_sim 13y ago
I wrote a javascript library that detects the standard time, the daylight saving time for the current time zone : https://github.com/dsimard/timezonedetect https://github.com/dsimard/timezonedetect Garry Tan, cofounder of posterous, said of it : "Finally, timezones in javascript done right. The world has been made a better place via this fine javascript library."
sigsergv 13y ago
Timezone — is not just offset! Proper use of timezones is not so simple unfortunately. And browser usually doesn't provide correct timezone name that could be used reliable (like Europe/Berlin).
bluesmoon 13y ago
I started to write a response, but it grew too long, so I wrote this blog post instead: http://tech.bluesmoon.info/2013/08/dont-guess-at-timezones-in-javascript.html http://tech.bluesmoon.info/2013/08/dont-guess-at-timezones-i... tl;dr: the timezone you use depends not just on the user and their environment, but also the event and its duration.
dalore 13y ago
GMT? Surely they mean UTC as GMT is no longer precisely defined by the scientific community.
dspillett 13y ago
> Luckily, the browser already knows what timezone the user is currently in Incorrect (though usually true, I'll grant). I've often seen people with older Windows laptops (newer Windows variants, 7 and 8 certianly Vista maybe, are much better at this) that are set to display UK time but think that they are in UTC-0700. This can be fun when using file synchronisation tools... If the OS doesn't know its timezone then the browser won't either. This is a moot point when you are talking to just one user, until that user fixes their clock settings of course, but becomes a significant issue as soon as you need to coordinate timed actions between users. Detecting the local time offset from your reference clock isn't always useful either: the machine's clock could be completely wrong so it says 01:23 where the user's wall-clock says 21:00 and your reference time matches neither. Also some users may wish to fix your interface to a timezone other than the one currently set on the device they are currently using. Someone on holiday or on a business trip might want to keep some things linked to local time back home so they find it easier to coordinate with people there. Conversely someone currently in their home timezone might want to force your interface to match a non-local timezone for coordinating with teams/friends elsewhere in the world. You can't rely on them adjusting their clock in this circumstance as they may not be using their own machine and so might not be able to adjust the time/timezone settings (or may wish to keep them accurate to current local for other reasons). tl;dr: Dealing with time values when there are any international concerns it harder than we tend to assume.

96 points by neilk 13y ago

jstz is a great JS library that we use at my startup for automatic timezone detection http://pellepim.bitbucket.org/jstz/ http://pellepim.bitbucket.org/jstz/

icebraining 13y ago

UTC, not GMT.

dfc 13y ago
I had the same reaction. Whenever I read GMT I know instantly that the author is not a big time nut and to take the rest with a grain of salt...

kintamanimatt 13y ago

This pretty much breaks progressive enhancement. If anything, the user's time zone should be first estimated from their IP address with a setting to override it. The client side solution to further refine it should be piled on top of this last, if possible. JavaScript is useful, but nobody should assume it's present. Also, it should be noted which time zone a time is in. A naked date/time is about as useful as saying that you're 3 units away from me. What unit does "unit" represent? shrug

crazygringo 13y ago
1) Exactly. This doesn't help at all with server-side rendering of times, which is usually the use-case (times associated with forum comments, etc.). IP address detection is pretty annoying to do (and doesn't help with VPN's etc.), but a quick <script> in the <head> of any page that does an instant "redirect" to put the JavaScript timezone info into a server-side session variable is a functional, albeit hackish, solution. (If you don't have JavaScript enabled, then just serve up UTC times, it's an edge case.) 2) Usually your times are stored server-side in UTC, so you never have to worry about timezones anywhere. It simplifies things a great deal. "Naked" = UTC. You assume that, whenever it's stored, it's already been translated from the user's timezone when the date was initially generated, or else the time it happened on the server was the actual time.
- kintamanimatt 13y ago
  Sorry, I meant naked date/times that are displayed on a page. It might be that site A gets the user's local time zone correct, but site B, C, and D don't. By displaying the time zone abbreviation next to the displayed time it removes all ambiguity and possibility for error. Also, if it's a time zone abbreviation that's displayed (e.g. EDT) make sure to mark this up properly and fully explain which time zone and country this is for. I can't remember which, but there are some time zones that have the same initialisms. Some don't have initialisms at all, and users from, say, Poland might not know what PDT is either.
  - eksith 13y ago
    This is what we did on a recent project. The times were left at UTC with a hover tooltip (JS with a fallback to title="Coordinated Universal Time") and we used the "timeago" plugin for jQuery http://timeago.yarp.com http://timeago.yarp.com . So far, no complaints.
trevoro 13y ago
By your logic I'd be running a WAP site over Gopher to satisfy the progressive enhancement ethos. At a certain point it's absurd to assume javascript isn't there. [1] What brought on this particular use case was a JSON response where all the times were in UTC. I'm not really into forcing a technique on someone when it isn't required. If that's not your use case, then you don't have the problem! [1] http://www.mozilla.org/en-US/firefox/23.0/releasenotes/ http://www.mozilla.org/en-US/firefox/23.0/releasenotes/
- kintamanimatt 13y ago
  No, that's patently absurd, although I have been known to use w3m while doing work in vim, and I'm super grateful when a site is usable from a text only browser. Screen readers and bots (including search engine spiders) have an easier time with well written HTML. Progressive enhancement is far better for the end user and not all that hard to implement. Some people choose to disable JavaScript, and there are compelling reasons to do this especially if, for example, you're using TBB and want to minimize your attack surface, as has been demonstrated recently. JavaScript isn't evil by any means, and it's really important for creating cool shit, but it should never be required. If I can't use your site with scripts disabled, neither can a lot of other people. Sucks to be them though, right?
  - lucisferre 13y ago
    > it should never be required What a ridiculous statement. Lots of things are "required" if you want certain products to be useful. An XBox is required if I want to play XBox games. Hell you require a web browser just to be able to enjoy the pleasure of checking that "disable javascript" box (though be careful you don't use Mozilla) in the first place (I mean you could use CURL but then you don't actually get to disable javascript). The point is lets stop kidding around about Javascript here, no-javascript guy. > If I can't use your site with scripts disabled, neither can a lot of other people. People who need to disable Javascript are a vanishingly small portion of any potential market, there are many more use cases as far as web apps go where javascript is essential to any decent user experience. Not everything built on web technology is only about content these days. If you don't want to use that technology be my guest, but don't pretend your an important market to people developing on that technology. > Screen readers and bots (including search engine spiders) have an easier time with well written HTML. True but two things. 1) Web applications rarely rely on SEO outside of landing pages and a content strategy neither of which should rely on javascript for obvious reasons. 2) Designing applications for disabilities is extremely hard. Much harder than simply using "well written" HTML. Do you know how hard it is for blind people to play most video games? Again we're talking about interactive applications, not simply content. With content there is no problems but as we already went over the web is not only content now. Edit: One more thought, technically translating the time to the local timezone setting of the browser is "progressively" enhanced. You could always just display UTC time if JS is disabled assuming that was important enough to your users to disable JS (or for bots).
TazeTSchnitzel 13y ago
Progressive enhancement of dates is easy. Output UTC, update to local time zone with JS. Simple!
DigitalTurk 13y ago
Oh, I hate when website follow your approach. To start, it doesn't work if you use VPNs. Second, it doesn't update when you travel. Here's one example. Even though I'm logged into Google and used Google Maps' 'pinpoint my location' feature, Google Reader is currently emailing me my daily schedule (a feature I enabled recently) in the afternoon. That's also despite my appointments being annotated with timezone information. I call this bad engineering.
eli 13y ago
Geolocating the timezone based on IP is so fragile and likely to fail that IMHO it's not nearly worth the time to implement.
- justincormack 13y ago
  Indeed and will get worse with ipv6 rollout no doubt.
lvturner 13y ago
An option to override this is a must, I frequently use VPNs and as a result appear in many different countries through-out the day - It's bad enough with google repeatedly blocking my accounts for suspicious logins, without having to worry about timezone differences too. Also, it'd be nice to ALERT me when my timezone has changed and give me an option to keep the old one, or use what you think my current one is.
hrktb 13y ago
In this case progressive enhancement is offering a GMT date or other sensible default, and offer another date after javascript kicks in. Personaly, I think for anything where timezone is relevant, the best move is to always let the user manually enter the timezone he/she wants, or have it match the timezone of the event/service he's looking for, and of course allow for override, so changing timezone has to done client side. I.e. if I am in Germany and search from a flight taking off from Taipei two days from now, I don't care about the departure time from the German timezone. Same thing if I reserve a restaurant in Germany while I am in Taipei, you'll want the german time for the reservation. For something internationally broadcasted showing the UTC time as default and provide a way to adapt to other timezone is OK, as the event has no local anchoring anyway. People can do the calculation for timezones, eventually some opt to not change their phones timezone to keep in sync with other more important schedules, etc. Trying to do 'smart' things seamlessly is often just screwing with the user.

tjoff 13y ago

Fortunately operating systems on laptops and mobile devices all adjust timezones automatically whenever they connect to the internet. My laptop has never changed timezone automatically. And that is a feature in my eyes. How can you assume that just because I'm doing a weekend trip that I want my whole life to be centered around the timezone in that particular place?

crazygringo 13y ago
Most people want their clocks to be correct, local time, including their laptop clock. It's a better assumption to make for most people. Of course, it can always be turned off for others, like yourself! :)
- tjoff 13y ago
  Citation needed. I'd say that a vast minority (that actually cares) wouldn't want the OS to change the timezone behind their back on a laptop. On a phone (which also acts as a wrist watch for most people), yes. Laptop, just no. What OS does this? And how?
  - crazygringo 13y ago
    OSX for sure. "Set time zone automatically using current location". Checkbox inside system preferences. I think it's pretty safe to say most people want their laptop's clock to match their local time, because how is a wrong clock useful? Of course, if you're travelling for business with complicated schedules and meetings in home times, you clearly might have different needs, but most people just want their clocks to be right. And you certainly don't want to keep your original timezone but change the clock setting -- then just everything's wrong! :)
    - tjoff 13y ago
      On my laptop, any time that isn't the current time in my hometown is the wrong time. And it is moronic for the OS to do this change behind my back (I don't know how OS X present this but thankfully Windows 7 doesn't do this madness by default). How do I know that my OS got the time right? (did it perhaps get the time from my VPN location? was the network I connected to badly configured?) Since a laptop isn't connected to the net at all times I also have to consciously be aware of whether I've even been connected yet in this particular time zone.

rustynails 13y ago

If you do localise content, make sure it's what your users want. When it comes to Rotten Tomatoes, I'm glad it asks my location because I prefer US film reviewers to my local film reviewers. If I let Rotten Tomatoes know my time zone, I can't access US reviewers (that I'm aware of).

anigbrowl 13y ago

While we're at it, why (if I'm in the US) do I have to keep selecting my state, town etc., in addition to my zipcode?

joevandyk 13y ago
It's less work for the developers, who might have more important things to do?
- anigbrowl 13y ago
  More important than accommodating the users, aka customers? Hmmm.
JSadowski 13y ago
Because zip codes do not equate to cities 1 to 1. Many cities have multiple zip codes, and some zip codes span multiple cities. Zip codes are based on postal routes, cities are not.
- anigbrowl 13y ago
  Zipcode plus address is usually plenty though. And it's certainly good enough to obviate the tedious selection of the state from a 52-item dropdown menu.
eric_the_read 13y ago
ZIP codes can be shared among multiple towns. Quite possibly multiple states, though I can't think of an example offhand.
- showerst 13y ago
  That's correct; via wiki - For example ZIP code 42223 spans Christian KY and Montgomery TN, and ZIP code 97635 spans Lake OR and Modoc CA. Zip codes are also non-contiguous in some areas, and not bounded-polygons in others which makes them really bad for geo purposes.

taylodl 13y ago

It seems most people resort to storing time in UTC, but this isn't your only option: any fixed time zone will do. If you're in a corporate setting and the majority of your users are in the same time zone as your servers, then it makes sense to use that time zone. There's fewer date conversions that way. For half the year there will be basically no conversions and for the other half it's a 1 hour DST conversion - which many time handling libraries have optimized (I'm in the United States in an area that observes DST for half the year).

TazeTSchnitzel 13y ago
>any fixed time zone will do. Theoretically, yes. In practice, you should just use UTC. >If you're in a corporate setting and the majority of your users are in the same time zone as your servers, then it makes sense to use that time zone. No it doesn't. Use UTC. The Internet does not have a time zone. >There's fewer date conversions that way. Your library is probably "converting" the date anyway, UTC or not. >for the other half it's a 1 hour DST conversion - which many time handling libraries have optimized Is it really that slow to convert a date?
apaprocki 13y ago
Storing datetimes in fixed timezones that do not observe DST will do (but it is still not recommended), but you can't say any fixed timezone will do. Say you're storing datetimes in EST/EDT and you have a global audience. On the day the US goes back to standard time, how do you know whether 1:30AM in your database is the "first" 1:30AM or the "second" 1:30AM when you need to display the event to someone in Dubai? Are you going to store some extra metadata to indicate whether DST was in effect beside the datetime? Just store UTC.
- taylodl 13y ago
  A fixed time zone doesn't shift for DST, otherwise it wouldn't be fixed - by definition. All you need is a fixed reference point. There's nothing sacrosanct about UTC.
  - 13y ago

btipling 13y ago

I want to agree, but there are times when you have to ask for timezones, like when you want to collect and present data in discrete time units like days. If a user wants to know how many app installs they have per 'day', you have to know what time the time the day they care about begins and ends before you start dumping data into those time delineated buckets. It's not always the timezone their browser uses. Especially not with agencies that are providing these services for clients that are somewhere else.

jenseng 13y ago

UTC offset is well and good if you are talking about today, but as soon as you start displaying past or future datetimes, DST will bludgeon you over the head. And depending on your app, users might want control over the timezone. When a teacher creates an assignment in canvas-lms, the due date defaults to midnight of the selected day. It would be surprising if it set it to 2am, just because the teacher happened to be traveling when the assignment was created.

excitom 13y ago
Exactly. I have run into this problem with event calendars. For example: Schedule a recurring event for 1pm. It happens to be EDT at the moment so you store the event date/time in UTC by adding 5 hours. Then, in days, weeks, or months, we change to EST. The 1pm meeting is now showing at noon. To fix this I run a cron job on the ST/DT boundaries that increments or decrements stored date/times in the event calendar.

amiruci2 13y ago

I looked into getTimezoneOffset when implementing pre-orders here at Gumroad and realized that technically this is incorrect: "Luckily, the browser already knows what timezone the user is currently in, so we can make use of the getTimezoneOffset() function" Getting the timezone offset isn't the same as getting the timezone. Granted that in certain cases having the offset is good enough, but sometimes you need the actual timezone. In my example I needed to know when a merchant wants their pre-order to be released. For that to work predictably I needed to know their exact timezone in order to adjust the time for daylight saving properly. Remember that there are quite a few timezones that are UTC-7 and they can behave differently in regards to daylight saving.

dan_sim 13y ago

I wrote a javascript library that detects the standard time, the daylight saving time for the current time zone : https://github.com/dsimard/timezonedetect https://github.com/dsimard/timezonedetect Garry Tan, cofounder of posterous, said of it : "Finally, timezones in javascript done right. The world has been made a better place via this fine javascript library."

sigsergv 13y ago

Timezone — is not just offset! Proper use of timezones is not so simple unfortunately. And browser usually doesn't provide correct timezone name that could be used reliable (like Europe/Berlin).

bluesmoon 13y ago

I started to write a response, but it grew too long, so I wrote this blog post instead: http://tech.bluesmoon.info/2013/08/dont-guess-at-timezones-in-javascript.html http://tech.bluesmoon.info/2013/08/dont-guess-at-timezones-i... tl;dr: the timezone you use depends not just on the user and their environment, but also the event and its duration.

dalore 13y ago

GMT? Surely they mean UTC as GMT is no longer precisely defined by the scientific community.

dspillett 13y ago

> Luckily, the browser already knows what timezone the user is currently in Incorrect (though usually true, I'll grant). I've often seen people with older Windows laptops (newer Windows variants, 7 and 8 certianly Vista maybe, are much better at this) that are set to display UK time but think that they are in UTC-0700. This can be fun when using file synchronisation tools... If the OS doesn't know its timezone then the browser won't either. This is a moot point when you are talking to just one user, until that user fixes their clock settings of course, but becomes a significant issue as soon as you need to coordinate timed actions between users. Detecting the local time offset from your reference clock isn't always useful either: the machine's clock could be completely wrong so it says 01:23 where the user's wall-clock says 21:00 and your reference time matches neither. Also some users may wish to fix your interface to a timezone other than the one currently set on the device they are currently using. Someone on holiday or on a business trip might want to keep some things linked to local time back home so they find it easier to coordinate with people there. Conversely someone currently in their home timezone might want to force your interface to match a non-local timezone for coordinating with teams/friends elsewhere in the world. You can't rely on them adjusting their clock in this circumstance as they may not be using their own machine and so might not be able to adjust the time/timezone settings (or may wish to keep them accurate to current local for other reasons). tl;dr: Dealing with time values when there are any international concerns it harder than we tend to assume.