TimeZone support

[mattjohnsonpint]

Do you have plans already on how to shim the enhanced TimeZone support?

[andyearnshaw]

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.

[mattjohnsonpint]

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:

• moment-timezone
• bigeasy/timezone
• walltime-js
• timezone-js
• tz.js

(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:

• jsTimeZoneDetect

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...)

[andyearnshaw]

Thanks, I'll make sure to read up on this when I get around to it :-)

[NorbertLindenberg]

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

[jerone]

I was wondering if this being worked on?
The post in #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]

@jerone the Intl PR was already merged into node's v0.12 stream.

[jerone]

@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?

[srl295]

@jerone Can't answer your question on v0.12 but see nodejs/node-v0.x-archive#7676 (comment)

[andyearnshaw]

@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.

[caridy]

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'`

[longlho]

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 😄

[mattjohnsonpint]

@longlho - moment-timezone has gotten a lot better lately. :)

[caridy]

@longlho do you want to give it a try now that the code is a little better organized? jejeje

[longlho]

lol sure 👍 :)

[kennethaasan]

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?

[caridy]

I'm still looking for a volunteer :)

[longlho]

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.

[mattjohnsonpint]

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.

[mattjohnsonpint]

Also, note that ECMA-402/2.0 makes a lot of the time zone stuff required instead of optional.

[longlho]

yeah agree w/ @mj1856

[jpierson]

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?

[caridy]

@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 ;)

[mattjohnsonpint]

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"

[caridy]

@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 :)

[efkan]

Gentlemen, is there any progress about this issue?

I got stuck on timeZone is not supported

[xdissent]

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.

[caridy]

@juandopazo can you work with @xdissent on this alongside the other effort from your side around https://github.com/yahoo/date-time-format-timezone

[markandey]

@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.

[caridy]

@markandey does it work well with Intl.js? Is it already part of polyfill.io? Maybe an example of how these two works together.

[markandey]

@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.

[caridy]

Ok @markandey, let's get that done first, cc me on the PR to ft polyfill service, and once we get it there, we can document how to use both polyfills together to support timezone.

[fgerschau]

What is the status of this issue? The documentation says that timezones are still not supported...

[longlho]

@fgerschau u can use this polyfill in conjunction with https://github.com/yahoo/date-time-format-timezone

[bramski]

Ermagerd. How has this never been addressed? A lot of us using intl as a polyfill for react-native.
facebook/react-native#25595

[srl295]

@bramski does the above comment #19 (comment) solution work? If so, perhaps the docs should at least be updated to mention it?

[bramski]

It does! But this is hours of me chasing around this issue: moment/luxon#541

[longlho]

This repo unfortunately isn't really actively maintained as browsers have caught up fairly quickly with Intl APIs.

[bramski]

Yes but the polyfill is needed on react-native Android where the Javascript runtime does not provide Intl and will never support it.

[longlho]

Sorry I don't use React Native so I'm not sure but we've received similar issues over at react-intl. Do these instructions work? https://github.com/react-native-community/jsc-android-buildscripts#international-variant

[bramski]

Saved my day, thanks @longlho! Yes this polyfill is not needed on react-native if you have it compile with the intl version. Turns out the developer previous to me both included intl and compiled the international JSC so our react-native app broke in this really weird way when 0.59 upgraded the build configuration. Only the time zone support broke giving me hours of headache trying to track it down when instead it should have been obvious that Intl was just gone! That dude owes me beer....

[chrisheninger]

@longlho a combination of jsc-android-buildscripts + intl + date-time-format-timezone fixed the Android portion of my react-native app. Thank you! 🙂🙇‍♂️

Edit: After a little more testing it looks like intl + date-time-format-timezone did the trick. 👍 (for reference, I was running into issues when using https://github.com/marnusw/date-fns-tz)