Using Javascript, is it possible to get a client's Time Zone ID that maps to the Time zone IDs (or Time zone name) in this list?
The browser itself is unlikely to know about that list in general, as they're Windows-specific IDs. You may be able to adapt existing time zone detection Javascript code to use the Windows time zones itself, but it's likely to be some work.
I'm unaware of anything built into standard Javascript which will give any sort of time zone ID, but I know there are some detection packages available which probe the UTC offset at various points in time and deduce the time zone from that. I haven't used any of them personally, so you'd need to test it yourself. (I have no particular recommendations.) Such packages are likely to give you an Olson/TZDB/zoneinfo/IANA time zone ID; you could use my Noda Time project to then use that time zone, or convert it to the closest Windows time zone.
Note that any such detection may well be error-prone due to differences between the browser's time zone database and anything on the server side; you may well wish to prompt the user for confirmation, using the detection as input to suggest the most likely options.
Related
Using the DateTimePicker in Google Apps Script, I can have the user choose a date and time, and I can use setTimeZoneOffsetInMins to present a UTC date in the correct time zone.
The problem is that fixed timezones don't obey daylight savings time. I don't know before the user enters the date and time whether they'll be entering a time in EST or EDT, and so the timezone offset is guaranteed to be wrong for about half the year.
Is there a solution?
At the current stage, there is no direct method of achieving your task.
Just like suggested above, the best solution in this situation is to create a feature request on Google's Issue Tracker here and provide all the necessary details.
Reference
Apps Script Support.
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.
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.
"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.
I read some articles regarding web applications which depend on the date and time and geographical position.
I am interested in finding here a few best practices and even solutions for java web applications which client side happens to be on Angular.
I am looking for the best way to store the dates and times in my database so that I can determine their values based on user's location. We have some help here from the Javascript side which can determine the user's timezone.
Any advices, best practices and solution would be great.
I want to know from your experience what is the best way to do this thing because each article I read had a slightly different solution and that small diference caused iasuea later.
You may want to check out Moment.js, and specifically the Timezone add-on if you haven't already... it will take ISO 8601 datetime formatted string by default, the industry standard on any platform.
The Timezone is useful in dealing with timezones and converting between them etc.
This format encodes the UTC time with a timezone part, with high precision.
Now, before you mark this as a duplicate, please note that all the useful answers in the possible duplicate provide functions which work in relation to the current system time, which I cannot accept.
What I want, is that the current time in, say, for example, New York, be consistent to all users, no matter what their time settings are.
For example, I have two computers here, and one is 3 seconds behind the other, and this leaves an unacceptable gap, as my task involve pinpoint precision (slightly exaggerated, but you know what I mean).
How can I overcome this? Must I get the server time and somehow convert it? If so, I'm using PHP.
Hope to not be wrong but javascript is loaded on user machine, not on the server so you will allway get the visitor date/time using javascript. you can use php to get the date/time because is loaded on the server and pass the dates to javascript.
Hope this help
You need to use a timezone library to do this in JavaScript. See my answer here.
The scripts are small, but because they require the timezone database, it can get unwieldy for a client application. You're probably better off doing the conversion server side. Perhaps the pytz library will be useful to you.
Now, before you mark this as a duplicate, please note that all the useful answers in the possible duplicate provide functions which work in relation to the current system time, which I cannot accept.
What I want, is that the current time in, say, for example, New York, be consistent to all users, no matter what their time settings are.
For example, I have two computers here, and one is 3 seconds behind the other, and this leaves an unacceptable gap, as my task involve pinpoint precision (slightly exaggerated, but you know what I mean).
How can I overcome this? Must I get the server time and somehow convert it? If so, I'm using PHP.
Hope to not be wrong but javascript is loaded on user machine, not on the server so you will allway get the visitor date/time using javascript. you can use php to get the date/time because is loaded on the server and pass the dates to javascript.
Hope this help
You need to use a timezone library to do this in JavaScript. See my answer here.
The scripts are small, but because they require the timezone database, it can get unwieldy for a client application. You're probably better off doing the conversion server side. Perhaps the pytz library will be useful to you.