Add support for other time-zones

[aymericbouzy]

Why is there support only for 3 timezones? Why not support all of them? I have an issue with my server being in EDT timezone, and I'd be glad to check everything will be fine with this specific timezone.

[Jimbly]

Primarily because it hasn't been needed since any code that is going to fail will fail in any timezone which supports daylight saving time (assuming your tests test a reasonable number of times). You're welcome to add more if you think it would be useful for your use case!

That being said, EDT (assuming that's Eastern Daylight Time) is the timezone used by US/Eastern for part of the year, so that is one that is already supported.

[Jimbly]

Sorry, I was not quite correct... any buggy code will fail when either in a timezone with DST, or when ran in two different timezones, depending on what the bug is, so as long as there's more than one timezone supported, and at least one uses DST, any bug should be reproducible.

[malcolmocean]

I've had code that in principle could fail with any positive TZ offset, but in practice fails in Australia but not Europe because the cases are less likely to show up when it's only a few hours positive. I suggest that including an Australian timezone (some of which also have half-hour offsets) would therefore be prudent.

[Jimbly]

That's a reasonably different timezone than others, I've added Australia/Adelaide (largest non-integral timezone offset) as an option, updated the README and published to NPM as v1.0.13.

[hypnoboutique]

I added a custom timezone (always BST, for testing daylight savings in the UK regardless of system time) like this:

jest.mock("timezone-mock/lib/tzdata.js", () => ({
  UTC: {
    names: [0, "UTC"],
    transitions: [0, 0, Infinity, 0],
  },
  BST: {
    names: [1, "BST"],
    transitions: [0, 1, Infinity, 1],
  },
}));

[jacobwahoo]

Can you at least add the east and west extremes? I've got code that needs to check if a local date fits on any of the local calendar dates covered by a UTC interval, and there are edge cases around the extremes

As an example, if I have a UTC interval from 2022-02-09T10:00:00Z to 2022-02-10T10:00:00Z (start date inclusive and end date exclusive):

• in every time zone covered by this library (and most of the time zones in the world), the local calendar days are 2022-02-09 and 2022-02-10
• in UTC-10, the only calendar day covered is 2022-02-09
• in UTC-11 and UTC-12, the local calendar days are 2022-02-08 to 2022-02-09 in local dates.
• in UTC+14, it only covers 2022-02-10

[Jimbly]

@jacobwahoo That's a compelling reason to need those! A PR would be welcome, I think import.js has comments on how to import a different timezone, from a Linux system, however I'm on Windows at the moment, so if you want to take a stab at it, feel free!

[Jimbly]

All UTC timezones are now included thanks to @jacobwahoo as of v1.3.1.