Unit tests fail when using TZ (UTC+12:00) Auckland, Wellington

[Alexandr Nikitin]

In unit tests we create the test date using new Date(intValue) constructor which creates date in UTC format.

    // Tue, 07 Jun 2011 18:51:45 GMT
  , TestTime = new Date(1307472705067)

For TZ that significantly differ from UTC e.g. (UTC+12:00) Auckland, Wellington unit tests fail when we test days in local TZ

assert.format('%A', 'Tuesday') // Wednesday in UTC+12
assert.format('%a', 'Tue') // Wed in UTC+12
...
assert.format('%D', '06/07/11') // 06/08/11 in UTC+12
assert.format('%d', '07') // 08 in UTC+12

[Sami Samhuri]

The tests are definitely brittle and tailored to run in a specific timezone. We can do better.

Tests that involve the day or weekday would need to be corrected by at most 1 day behind/ahead and that should be relatively easy. Tests that involve hours should be easy to correct in most cases unless we hit some daylight savings edge case.

Maybe we could test a few timezones and cover enough ground to hit everything. If we test -12, -6, 0, +6, and +12 that should be fairly comprehensive.

Another option is to just keep a map of timezone names/abbreviations to their offsets and support any timezone. That might not be so bad actually.

[jasen-b]

Chatham islands (Pacific/Chatham) +12:45/+13:45 and Western Samoa (Pacific/Apia) +13/+14 are two corner cases that may be relevant to the test suite.

Can the test suite be implemented so that it starts with the local offset (which should be easy to measure) and then checks the results for consistency.

Any tests that assume that DST starts in March or April and ends in September or October will fail most places south of the Tropic of Cancer.