How does toLocaleString() get timezone in Javascript

Question

Background Information

I am struggling a little on an SPA dealing with time zones. I am looking to capture the current time when a user clicks a button, along with the time zone according to their machine.

My current attempt is to call currentDate.toLocaleString() (see documentation here) and rely on the time zone it is giving me. I've refined that by using 'en' and 'short' arguments, which provide me with a very pretty answer. I am also only supporting chrome (for now anyway) which supports this feature.

Question

My problem is that I need to be able to confirm the degree of accuracy of this call. Which means I would like to know HOW this information is being derived. For example, is it derived from a guess table based on offset? does it query the OS? is there some other system I don't know?

Details

We have some legal constraints on the dates we're gathering, but legal is pelting me with some quite technical questions about exactly how inaccurate our time zone can be, and under exactly which circumstances. The information will eventually be auditable, and it would appear we may be putting some caveats in somewhere based on the answer.

Bonus points if someone can point me in the direction of the code that impliments this feature in chromium so I can confirm for myself (legal doesn't care about that much, but I'm just curious now)

Double Bonus Points if someone can point me in the direction of the most formally accurate way of establishing a string representing time, date, and timezone for the moment of a user interaction in a browser (particularly within the javascript on the browser)

EDIT

I am aware of the browser differences, in broad strokes at least. I am only supporting "chrome" though we don't specify version, we will be run on modern business owned machines, so we can expect somewhat recent versions. That said, if there is a specific effect on the overall accuracy of the time zone portion of the call (the only portion I'm using) I would love to look deeper into that.

We are storing Epoch time (browser) and Epoch time (server) as well as offest (browser) all on top of this piece of information. That said, the only piece of information being displayed to non-technical users is (right now) the time zone, so it has some pressure to be as accurate as possible.

And yes, I checked moment.js and moment timezone, don't get me as close as toLocaleString() (did some hand testing for accuracy)

Final Response

I was aware that this was an extremely challenging problem, but I've learned that it was even more troublesome than I credited it with. Thank you for the information on the limitations faced here, which at the very least will provide our business users with a very clear idea of just how much of a compromise this data would be. Thank you very much for leading me as far from my ignorance as I could get! ^_^

Man, time is hard.

It depends in part on the specific browser - "locale used and the form of the string returned are entirely implementation dependent." — Noah, Dec 19 '16 at 22:49
`toLocaleString` will give you an implementation-dependent string. In most cases, it is intended to be *human readable* and it is *localized*. The value you receive could be quite different on different OS, browser, and version of browser. What are you doing with this value once you receive it? — Matt Johnson-Pint, Dec 19 '16 at 22:50
Also, have you read [this](http://stackoverflow.com/a/23255663/634824), [this](http://stackoverflow.com/a/22625076/634824), and [this](http://stackoverflow.com/a/16526897/634824) already? — Matt Johnson-Pint, Dec 19 '16 at 22:52
A Date instance can return the current timezone offset using *getTimezoneOffset*, however it does not know what the name of the time zone is. It can be reasonably accurately deduced by testing whether daylight saving is used and when. Note that the value returned by `Date.now()` is based solely on the host whose settings can be changed to anything that suits the person in control, I would expect its forensic accuracy to be very questionable. — RobG, Dec 19 '16 at 23:02
I am, unfortunately and painfully, aware that there are fundamental limitations, though those three links Matt are amazingly informative. In this case I'm a little more interested in the exact limitations of this specific approach to the problem, or a demonstrably superior attempt. We're also storing epoch time (browser) and epoch time (server) and reported offset (browser) in addition to this piece of information. — Suni, Dec 19 '16 at 23:07
Why no just sending UTC times to the server and bypass all the hassle of dealing with timezones? — Boldewyn, Dec 19 '16 at 23:18
@Boldewyn - if the OP could do that, they could instead just take the UTC time of the server and call it done. I think there is something more to the necessity of local time and local time zone here that we are not being told about. — Matt Johnson-Pint, Dec 19 '16 at 23:20
Our application involves a lot of international collaboration, involving people performing modifications of a tightly controlled and regulated piece of data in basically any possible nation. This creates a lot of information our users want to see, in a lot of ways. Local time, including zone, is very useful for noticing dangerous activities quickly, or so our users tell us. — Suni, Dec 19 '16 at 23:24
@Suni—if you are genuinely interested in international trade then all times should be UTC. The geographical location of the user will determine the time zone, it can't be reliably determined from the device itself. The agreements themselves should be written using UTC, if "local" times are used then the business logic must employ equivalent logic based on some declared datum (e.g. "Berlin local time"), but the timestamps should still be UTC. — RobG, Dec 20 '16 at 01:10
Oh, for me, Chrome's *toLocaleString* does not include the timezone. Its *toString* does, but only abbreviated. — RobG, Dec 20 '16 at 01:45

score 3 · Accepted Answer · edited May 23 '17 at 11:59

The only thing you can guarantee is that the current time, and the current time zone offset associated with the current time is the one that is in effect on the user's computer - as set by the user.

var d = new Date();  // the current time on the PC running this code
var o = -d.getTimezoneOffset() / 60; // the current UTC offset on the PC running this code

The offset alone does not tell you the full time zone (see "time zone != offset" in the timezone tag wiki), but does tell you how far from UTC the local time was for that particular point in time.

Both of these values are based on settings that the user can usually control on their PC, so from a legal perspective, you cannot trust that they are anything in particular.

The values you can get from toLocaleString are locale-specific, and implementation dependent. In many cases, they are determined via ICU, which in-turn, uses values from CLDR. The time zone itself is always pulled from an OS setting, which may be a TZDB identifier, or a Microsoft Windows time zone setting that goes through CLDR mappings.

If you really want to dig in, you can see the API docs for the TimeZone class in ICU. Chrome likely uses the createDefault function of this class to decide what the time zone is on the machine, and the getDisplayName function of this class to produce the result shown by toLocaleString.

WRT alternative approaches for increased accuracy, there's not much you can do in this area, because ultimately you trust your user to give you accurate information. However, if you have some other piece of data that you can gather accurately (such as GPS position), you can try one of these techniques to resolve the time zone. Keep in mind a clever user might still be able to spoof their location, or you may just have inaccurate location data depending on how it was derived, but it's usually more trustworthy than a setting the user can choose - especially on a mobile device.

Using location services can be fraught, it *might* use GPS, or mobile phone data, or may fall back to IP, which can be set by the user to anywhere. :-( — RobG, Dec 20 '16 at 01:42
@RobG - Sure, and really anyone can spoof API calls fairly easily too. It's just that usually faking location is slightly harder than manually setting your time zone or system clock, IMHO. — Matt Johnson-Pint, Dec 20 '16 at 17:00
Hi Matt, not talking about spoofing, just that it may fall back to IP which can be very unreliable through no fault or action of the user. — RobG, Dec 21 '16 at 04:31

score 0 · Answer 2 · answered Dec 19 '16 at 23:08

"Which means I would like to know HOW this information is being derived. For example, is it derived from a guess table based on offset? does it query the OS? is there some other system I don't know?"

In Short: The user specifies their locale within the browser at install / configure time.

In Long: Digging around, determining the locale of the user is based on settings built within the browser. Each browser has a list of languages in some preference order that is maintained to satisfy the locality query. These are set at install / configure time. This list of language preferences is used to satisfy locale issues, and is also passed on each HTTP request as a header.

See: http://norbertlindenberg.com/2012/12/ecmascript-internationalization-api/index.html#Identifiers

Essentially, the user is going to configure the browser with their language (either directly or via the version of the installer they select) so that it is usable to them. The browser keeps this information stored locally, it doesn't need to rely on the OS to keep this information.

"*determining the locale of the user is based on settings…*" only vaguely. On my PC, the "locale" is used only for timezone, it does not reflect my actual location by several thousand km. I could use 2 other timezones with identical offsets that are even more remote from my current location. ;-) Oh, and date, language and number formats are set independently of my "locale". — RobG, Dec 20 '16 at 01:12
Yep. Locale and time zone are separate things. Language or culture are never directly associated with time zone, nor should they be. I might be a US English speaker visiting Japan, for example. — Matt Johnson-Pint, Dec 20 '16 at 17:01