How does toLocaleString() get timezone in Javascript
<h2>Background Information</h2>

<p>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.</p>

<p>My current attempt is to call <code>currentDate.toLocaleString()</code> (<a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleString" rel="nofollow noreferrer">see documentation here</a>) 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.</p>

<h2>Question</h2>

<p>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?</p>

<h2>Details</h2>

<p>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.</p>

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

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

<h2>EDIT</h2>

<p>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.</p>

<p>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.</p>

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

<h2>Final Response</h2>

<p>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! ^_^</p>

<p>Man, <a href="http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time" rel="nofollow noreferrer">time</a> is <a href="http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time" rel="nofollow noreferrer">hard</a>.</p>