5 ms·

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

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.

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.