Navigator.timeZone

navigator.language is becoming more widely supported. Could we get a navigator.timeZone as well?

Recently I discovered that the default time zone is leaked in Chrome by the ECMAScript Internationalization API.

Intl.DateTimeFormat().resolvedOptions().timeZone
// => "America/Chicago"

Though, this seems to only be the draft behavior of the ECMAScript Internationalization API and not reliable yet.

On GitHub, we’re using this jsTimezoneDetect library (http://pellepim.bitbucket.org/jstz/). Its scary accurate. The clever hack for DST detection is just checking the TZ offset between January and June. That also helps you guess the hemisphere as well.

So in regard to privacy and fingerprinting, the data leakage already exists.

I’d also love to see the proposed Timezone header revisited (http://tools.ietf.org/html/draft-sharhalakis-httptz-05). We emulate this by basically setting a cookie named tz in the browser. A real header would be wonderful since its available on the first request, rather than having to wait to send the response, evaluate JS then set the cookie for the next request. Also, you could do Vary based HTTP caching based on the header.

Addressing fingerprinting concerns.

Leaving it up to UAs, navigator.timeZone could be stubbed to always return UTC (or even null) in private browsing modes. The same could be considered for new Date() if that entropy leak needs to be plugged as well.

Let me also make a case for server side time zone knowledge. Everything can’t simply solved by a client side <time> formatting element as mentioned in many old mailing threads. Though, I want localized time formatting natively in the browser, its not a complete solution.

At GitHub, we rely on server side tz for date grouping calculations.

Contribution dates are grouped by the clients TZ.

Traffic hits group by day in the clients TZ.

Commit listings are group by the clients date.

In all these cases we can’t simply send down every possible piece of day and have the client compute which date they fall under. Its way easier for the client to tell the server the TZ and have it query the database with the current date range based on the TZ.

I entirely agree that timezone and timezone changes is something we need to have in the Web platform. It is one of those low hanging fruits that we could solve quickly.

However, I am not sure that we want to add something in navigator if ES gives the same information. Why should we expose navigator.timezone if Intl.DateTimeFormat().resolvedOptions().timeZone would return the same value? Is the ES i20n API not a sure thing yet?

Something that might not be possible with the i20n API is to know when the timezone changes. If we can’t get that added to the JS API, we might want to add an event for this.

I guess @domenic could give us some insights here.

Totally agree we need something like this in the platform. That said, I have similar concerns as Mounir about the introduction of navigator.timezone if it’s possible for us to standardize on Intl.DateTimeFormat().resolvedOptions().timeZone returning the value you’re after. Yes - it’s verbose, which is unfortunate but if this worked cross-browser, that would serve your use-case, right?. The only compelling argument for .timezone I can see would be developer ergonomics and you could always wrap the current hack into something more useable.

As of the current 1.0 spec

In this version of the ECMAScript Internationalization API, the timeZone property will remain undefined if no timeZone property was provided in the options object provided to the Intl.DateTimeFormat constructor. However, applications should not rely on this, as future versions may return a String value identifying the host environment’s current time zone instead.

http://www.ecma-international.org/ecma-402/1.0/#sec-12.3.3

It doesn’t seem to be standardized yet. Seeing strange behavior in the wild where it returns "" or a non IANA zone like "CET" instead of "Europe/Amsterdam".

Intl.DateTimeFormat().resolvedOptions().locale should default to navigator.language.

What are your thoughts about the server side negotiation Time-Zone request header?

The benefit of the language native is that cross-browsers => cross-platform (eg. Node).

I agree with you that fingerprinting is not the concern here. Fingerprinting is pretty hopeless across the platform and I no longer believe that it can be mitigated through feature limitations. The line of defence should be the browser detecting that an origin is looking at many know fingerprinting pieces of information at once and reporting it to the SafeBrowsing DB for verification.

Regarding using an HTTP header the usual concern is that it adds bytes to every request, and in doing so may break packet boundaries, damaging performance. I suspect that this is not used often enough that including it for every request is an optimisation compared to the back and forth you describe having to do. That said, it may be the case that HTTP2 helps enough here that this could be included?

We need to get feedback to TC39 that the TZ should be reliable and not something applications shouldn’t rely on. @domenic? @slightlyoff? @dherman?

I think the Ruby on Rails community would love server-side automatic timezone configuration. All the infrastructure is in place to format dates in the current timezone and even annotate timestamps being inserted in a database with the current actors zone. The missing piece is actually knowing the actors TZ. Thats basically left as an exercise to the developer to implement some sort of user settings timezone picker or do client side sniffing.

I don’t know if there were interesting reasons why the time zone was left out of the first version of the Intl API or if it was just scoped out for v1. I’ve asked on es-discuss.

Dave

Is there a privacy aspect to this? If the returned value is Europe/London then you’ve got a fairly narrow geolocation window.

If the timezone is UTC-09:30 then you have a virtually certain chance of knowing someone is on the Marquesas Islands

Is this yet another privacy pop-up that the user will have to accept or dismiss?

At this point, Intl.DateTimeFormat().resolvedOptions().timeZone is well-supported across new versions of browsers. Would a new navigator.timeZone still provide additional value?