feat: add parse zone plugin

[LucaColonnello]

Closes #651

I'm opening this PR based on the discussion in the linked issue above.
This is something that affects many people as timezone is a complicated topic.

Example scenarios are:

• use the date timezone in format, rather than converting to the local one
• do calculations in the provided format, rather than converting to the local one
• display date and times with the original location in travel websites, rather than the user location (it confuses customers)

Example usage:

import dayjs from "dayjs";
import parseZone from "dayjs/plugins/parseZone";

dayjs.extend(parseZone);

const parsedDate = dayjs.parseZone("2016-12-21T07:01:21-08:00");

expect(parsedDate.format("MMMM D, YYYY, h:mm A")).toBe("December 21, 2016, 7:01 AM");

[LucaColonnello]

@iamkun let me know if you need me to do anything else, or add docs, I'm happy to progress this quickly.
Feel free to suggest more tests if you think anything here has not been accounted for.

Having this plugin as part of dayjs, I think we would be able to catch problems and benefit from the work people can put in OSS, rather than copying and pasting this code everywhere like the issue seem to imply...

[abdirahmanjama]

@iamkun

[vronifuchsberger]

this would also allow something like +44:00 - not a biggie, but maybe this could be changed to ^(.*)([+-])([0-2]\d{1}):([0-5]\d{1})|(Z)$ so it only allows possible timezones?

[LucaColonnello]

Interesting one here!
So, dayjs does its own validation on this, but not sure at what point it would fail (I've seen it's mainly when you try to format or using a getter).

I think we need some direction from @iamkun here to advice on the best approach, mainly as if we update the matching pattern and it doesn't match, it would just fallback to the default constructor, whereas now it passes the offset to the utc plugin (which I would expect to deal with).

[LucaColonnello]

I think we're just going to publish this internally to use as we need it, but I'll leave the PR open hoping eventually it will get merge or reviewed :)

[Va1]

@vronifuchsberger @abdirahmanjama guys, any ETA on when these changes will be released? it's a big pain :(

[vronifuchsberger]

not a maintainer, so unfortunately can't help you getting this in - we ended up publishing it internally in our company and re-use it in our repos until this (hopefully) get's merged 😄

[poush]

It would be amazing to have this released. For now, I will also try to use it internally :) Thank you for your effort guys!

[wh1t3h47]

This looks awesome!

[akkayaburak]

Thank you all! Please release this 🤕

[guyschlider]

really looking for this one.

[peter2gossell]

This is an essential feature for a library trying to be a replacement for moment! I'm going to have to use this internally until this is included in an official release.

[robertherber]

Would love to have this in dayjs! One thing I noticed when trying this out (which might well be a bug in the utc or timezone plugins) is that offsetName() doesn't render the result I expect:

const str = '2018-11-13T14:54:59Z'

const value = dayjs.parseZone(str)

expect(value.offsetName()).toEqual('UTC') // <-- this fails, it is my local timezone (currently GMT+1)
expect(value.format()).toEqual(str)

[M-Ivan]

I would love to see this in dayjs, will follow this.

@LucaColonnello Just FYI, this regex makes double colons optional in the offset. Just in case you mind in giving that support.

/^(.*)([+-])(\d{2})(?::?(\d{2}))|(Z)$/

Will support both 2013-01-01T00:00:00-13:00 as well as 2013-01-01T00:00:00-1300 as valid dates to parseZone

[alxnddr]

It would be so great to merge this plugin. Thanks everyone for your efforts!

[Simoon-F]

This is great.

[miguelski]

why is this still not merged?

[thijsdortmann]

Great addition! Currently also using this internally; would be great if this could become part of the next release.