

Stop asking users for their timezone – use per-device settings and JavaScript - neilk
http://trevoro.net/2013/whats-your-timezone/

======
kintamanimatt
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_

~~~
trevoro
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
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
> 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).

~~~
eksith

      People who need to disable Javascript are a vanishingly small portion of any potential market.
    

Depends on who your target demographic is. I'm a "no-javascript guy" and my
cousin is as too (well, "gal") for completely different reasons. She's on a
rubbish computer not living in the U.S. (read: developing country) so often
it's just faster and smoother to browse on a wireless connection with JS
disabled. You'd be surprised at how common this is.

I frequently disable it while browsing casually and, for about a month or so,
it was policy at work until we sorted out a few in-house security issues
(namely browsing etiquette for some of the folks). Our CMS was broken during
this time and the front UI was quickly re-written in plain HTML. After that,
we sorta left it that way.

    
    
      1) Web applications...
    

The original post makes no mention of "application" or "web site" for that
matter.

~~~
lucisferre
> You'd be surprised at how common this is.

Actually, I would. I would be completely surprised if it is common (by that I
mean at least more than IE6 usage) at all. However, you've presented no
evidence of this fact only anecdote. Seriously there is absolutely no evidence
that there is a growing popularity of no-js people out there. Perhaps for very
specific demographics, in which case I certainly hope whoever is building
product for them knows their customer well enough to know that or God help
them.

Either way they are not going to be building the latest in interactive
experiences or web-based gaming for your cousin with her rubbish computer are
they. That doesn't discount the fact that many people are building exactly
that these days.

I'm tired of people on Hacker News making blanket arguments like "never do
this" especially something as bland as requiring javascript. They have
absolutely no clue what they are talking about.

Bottom line is if I (and Google and 37 signals and countless others) can
choose to build something that doesn't support even IE8 I can quite happily
choose to require Javascript to use my web _application_. I would be an idiot
however if I required it for my blog.

~~~
eksith
Yahoo Blog on users with JS disabled (stats as of 2010):

[http://developer.yahoo.com/blogs/ydn/many-users-
javascript-d...](http://developer.yahoo.com/blogs/ydn/many-users-javascript-
disabled-14121.html)

For clients in the UK, it's a legal thing:

[https://www.gov.uk/definition-of-disability-under-
equality-a...](https://www.gov.uk/definition-of-disability-under-equality-
act-2010)

[http://www.rnib.org.uk/professionals/webaccessibility/lawsan...](http://www.rnib.org.uk/professionals/webaccessibility/lawsandstandards/Pages/uk_law.aspx)

FYI: Screen readers nowadays can run JS, but there are hiccups abound. Also I
don't recall seeing "never do this", though I did see this: "JavaScript isn't
evil by any means, and it's really important for creating cool shit, but it
should never be required" from
[https://news.ycombinator.com/item?id=6176036](https://news.ycombinator.com/item?id=6176036)
. Which, in context of the article, seems pretty reasonable to me.

This all started with when kintamanimatt mentioned that the article's
technique breaks Progressive Enhancement, "JavaScript is useful, but nobody
should assume it's present."

Obviously, I'll need to get an Xbox to play an Xbox game. I'll need Flash
enabled on the browser to play a game built on that. Same goes for JS. But,
again, the OP makes no mention of "applications" or "web sites" so I'm not
sure why you're bringing up "the latest interactive experiences or web-based
gaming" into this.

~~~
z92
The Yahoo link says JavaScript was disabled on 1% of visitors as of 2010.

That percent should be even lower now instead of being higher.

------
bluesmoon
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-i...](http://tech.bluesmoon.info/2013/08/dont-guess-at-timezones-in-
javascript.html)

tl;dr: the timezone you use depends not just on the user and their
environment, but also the event and its duration.

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

------
tjoff
_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
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
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
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
_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.

~~~
eridius
So if you travel to Tokyo for a week, you still want your laptop displaying
the time from your hometown? That seems rather unusual.

And for the record, OS X does it by sniffing for wifi access points. The
particular access points available at any given location is a pretty reliable
means of tracking location, assuming that there are any (if there are no
access points, it can't find your location, and therefore won't touch your
clock). The only exception are access points that themselves move, e.g. wifi
on planes. I would assume that these access points are disregarded.

This is the same system that iOS uses to enhance the GPS (especially on iPod
Touches and Wifi iPads, where you have no cell towers).

~~~
dagw
_if there are no access points, it can 't find your location, and therefore
won't touch your clock_

This is the part that scares me and has gotten me into trouble in the past.
Basically it means I do not know if my clock is local time, home time, time of
the last timezone I visited or something random and thus I cannot trust it.

This isn't just a hypothetical, but has bitten me in the past. Fortunately it
lead to me showing up for my train an hour too early rather than an hour too
late. But after that I never let my OS play around with my timezone settings.

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

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

------
icebraining
UTC, not GMT.

~~~
dfc
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...

------
dspillett
_> 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.

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

------
anigbrowl
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?

~~~
JSadowski
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
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.

------
rustynails
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).

------
cmadan
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/)

------
sigsergv
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).

------
taylodl
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).

~~~
apaprocki
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
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.

~~~
apaprocki
It wasn't clear what 'fixed' was, since that isn't normal terminology. I took
'fixed' to mean "pick a single timezone and stick to it".

If you need to pick a timezone which does not observe DST, that rules out
(generally speaking) most of North America and Europe and a lot of other
places. So maybe you want your new time base to be Asia/Tokyo, Asia/Shanghai,
Asia/Kolkata, Europe/Moscow? You're still at the whim of governments who
constantly tinker with DST -- sure Europe/Moscow is "fixed" now, but it wasn't
as close as 2 years ago.

To each their own, but I would not get into the business of depending on any
particular zone in tzdata staying as it is currently defined for any amount of
time in the future.

~~~
taylodl
I meant fixed as in unvarying. So we store our time data in EST (UTC-05:00),
instead of UTC. For half the year the stored time matches the local time it's
to be displayed in and so no conversion is required. The other half of the
year when local time is UTC-04:00 we only need to shift the stored time by one
hour to display it properly.

Many time handling libraries are extremely efficient at adding/subtracting an
hour from time. This is important because we have many legacy systems using
this data (think mainframe COBOL to today's latest technologies with a
smattering of everything in between). So it's not just a single time handling
library in use.

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

