dmtrKovalenko
Support for BigEasy's Timezone
I'm interested in support for BigEasy's Timezone library. It's main unique feature is that it uses strftime formatting tokens (from GNU's version of the UNIX date utility), as used in most C based backend languages. It's under 3K minified and gzipped.
If I can make a PR that implements the interface, do you have any concerns about maintaining it as part of date-io?
http://bigeasy.github.io/timezone/ https://github.com/bigeasy/timezone
I completed a first pass at the interface, and the only notable issues were that:
For the date method that parses iso8601 stamps, Timezone parsed the invalid example:
2018-42-30T11:60:00.000Z
as
2021-06-30T12:00:00.000Z
By rolling over the oversized fields. While that's arguably "incorrect", all real world timestamps will be generated by a database or API calls, and not hand written by humans, so malformed dates like these that are correctly formed but have oversized fields should be quite uncommon. As a human, it makes sense to me that "11:60" would be corrected to "12:00".
Since date was able to parse that invalid timestamp into Timezone's internal format, a number, isValid also reports that the invalid example is valid. Even though the iso8601 stamp is invalid, the result is valid representation of a date, and can be used for date arithmetic. That was unexpected, but ultimately seems like correct behavior.
For the .parse method, Timezone doesn't actually support general strptime parsing. It only natively parses RFC 3339 dates (which is compatible with iso8601). The example in the test (2018-10-30 11:44) happens to be a valid RFC 3339 date stamp, so as a first pass, I just ignored the format string and the test was green. There are various strptime ports, but there is not a clear leader, so my plan was to accept a user provided strptime method in the TimezoneUtils constructor, so they could pass in whatever implementation they wish.
From reading the docs, I agree with BigEasy's position that Timezone is a focused library that only deals with timezone aware date math and formatting, not general parsing. However, it would be nice to use the same locale data for strptime as his implementation of strftime — in my brief research of JavaScript strptime implementations, most only dealt with English.
@whitehat101 What prevents you to use BigEasy's Timezone? For instance, I would imagine you could control the component and concert the date with it.
