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.