Intl.js
Intl.js copied to clipboard
andyearnshaw
TimeZone support
Do you have plans already on how to shim the enhanced TimeZone support?
I havent decided how I'm going to do it yet, but it's definitely planned. I just haven't had the time outside of work, lately. It should just be a case of mapping the time zone values from the IANA database, but it's going to be an optional part of the flexibleBuild branch so that it doesn't bulk up the default build.
I'd be interested in reviewing when you do. There are a few other libraries that already have the IANA data implemented, and it can be a bit challenging. I'm not sure if you want to take any dependencies on other libraries or not. (I would guess not). But you could look at how others have done it.
These are general conversion libraries:
(I'm currently evaluating all of these for a shoot-out style blog post.)
And this one is focused on detecting (guessing) the computer's IANA time zone id:
Just listing them here in case you aren't familiar.
You may also run into problems with how ECMAScript 5 handles time zone rules. (Thar be dragons here...)
ECMA-402 implementations are not required to, and in fact should not, follow the goofy rules for time zone handling in ECMA-262 edition 5.1: http://www.ecma-international.org/ecma-402/1.0/#ToLocalTime
I was wondering if this being worked on? The post in https://github.com/andyearnshaw/Intl.js/issues/67 states that it's been looked at.
I'm asking this as I was looking for this feature and it might take a long time before Intl is merged and released in the stable branch of Node.js itself.
@srl295 You're right, indeed merged, not yet released. Any ETA when the v0.12 stream will be released (see only one related issue open)? Is it still relevant to build the timezones in this project?
@jerone Can't answer your question on v0.12 but see https://github.com/joyent/node/issues/7676#issuecomment-57535890
@jerone: sadly I haven't had any time to work on it. It is still planned, but #77 is a higher priority for me at the moment.
for the record, this is what we have in chrome today:
new Intl.DateTimeFormat('en', {
weekday: "long",
timeZone: "UTC",
timeZoneName: "short",
month: "long",
day: "numeric",
year: "numeric",
hour: "numeric",
minute: "2-digit",
second: "2-digit"
}).format(Date.now());
// "Wednesday, March 25, 2015, 10:08:13 PM GMT"
while the polyfill will output: ``'Wednesday, March 25, 2015, 10:11:54 PM'`
Having used to maintain timezone-js, timezone is a whole other can of worms that is both natively buggy cross-browser and confusing as well. Although it'd be great if it is supported :smile:
@longlho do you want to give it a try now that the code is a little better organized? jejeje
This will be very useful. I'm using this polyfill for node, and I want to generate a time with timezone specific settings from uts.
@longlho, plans for implementing timezone anytime soon?
I can try to take a look :) The core of it is the IANA tz parser which is hairy, and then mapping to this library itself.
Yes, parsing is tricky, and data maintenance is a pain.
Perhaps consider a plugin model. Expose some API in Intl.js that can be passed a function for time zone conversions. Then give example(s) of plugging in to existing libraries (like moment-timezone).
Doing it all yourself is possible, but may prove to be more hassle than its worth.
Also, note that ECMA-402/2.0 makes a lot of the time zone stuff required instead of optional.
I noticed and subscribed to this issue after posting a related question on StackOverflow. In my case I assumed that I would have to make use of a library like moment-timezone because I could find no mention of timezone support in the FormatJS or react-intl documentation. It sounds like from @caridy's comment that that there at least partial support for browsers other than Safari at the moment?
@jpierson that's correct. All browsers, except safari (which is under dev), have support for timezone. The polyfill doesn't as today! We need a brave soul to help with that. All the data is in CLDR, and I can help with the extraction process, and provision of the DATA, which is probably the most convoluted part, the rest should be easy ;)
Actually, most browsers don't have this yet. See http://kangax.github.io/compat-table/esintl/ under "DateTimeFormat" - "resolvedOptions().timeZone defaults to the host environment"
@zbraniecki do you know about this issue in FF?
@mj1856 thanks for pointing that out, I will follow up with your co-worker @bterlson as well to see when are they planning to fix that :)
We've got a branch with tz support, but it's the older spec IIRC, and it requires an external helper for tz data and conversions: https://github.com/bkon-connect/Intl.js/tree/tz We never sent a PR because of the external requirement (although looking at it now, it's totally optional). I'd gladly update it if I could get some guidance on how the external tool should ideally be integrated, or the go-ahead to include tz data and some utils directly.
@juandopazo can you work with @xdissent on this alongside the other effort from your side around https://github.com/yahoo/date-time-format-timezone
@caridy @xdissent
date-time-format-timezone is pretty much independent, which can polyfill intl.js implementation too. I started working on similar approach what @xdissent done. Then I realized that {locale+timezone data} combination is not easy to deal with.
Would be best if you simply direct people to use date-time-format-timezone polyfill instead.
@markandey does it work well with Intl.js? Is it already part of polyfill.io? Maybe an example of how these two works together.
@caridy yes they do work together. date-time-format-timezone has test for ie9 where intl is supported by intl.js and then timezones are supported by date-time-format-timezone . I am planning to make Pull request for polyfill.io, its not part of polyfill.io yet.