Tests fail with NaN when run in GMT +08:00, possibly others

[willwhite]

Set system timezone to GMT +08:00 (for example) and test fail with the following:

   chrono.test.js test missing timezone parameter: AssertionError: "NaN" == 3
    at Test.exports.test missing timezone parameter [as fn] (/Users/willwhite/chrono.js/test/chrono.test.js:62:10)
    at Test.runParallel (/Users/willwhite/.nvm/v0.8.18/lib/node_modules/expresso/bin/expresso:959:10)
    at Test.run (/Users/willwhite/.nvm/v0.8.18/lib/node_modules/expresso/bin/expresso:924:18)
    at next (/Users/willwhite/.nvm/v0.8.18/lib/node_modules/expresso/bin/expresso:867:22)
    at Test.run (/Users/willwhite/.nvm/v0.8.18/lib/node_modules/expresso/bin/expresso:925:13)
    at next (/Users/willwhite/.nvm/v0.8.18/lib/node_modules/expresso/bin/expresso:867:22)
    at Test.run (/Users/willwhite/.nvm/v0.8.18/lib/node_modules/expresso/bin/expresso:925:13)
    at next (/Users/willwhite/.nvm/v0.8.18/lib/node_modules/expresso/bin/expresso:867:22)
    at Test.run (/Users/willwhite/.nvm/v0.8.18/lib/node_modules/expresso/bin/expresso:925:13)
    at next (/Users/willwhite/.nvm/v0.8.18/lib/node_modules/expresso/bin/expresso:867:22)


   Failures: 1


make: *** [test] Error 1

[taketime]

I'm able to reproduce this by switching to a handful of timezones and running the tests (example: ALMT (GMT +8)). Sometimes the problem shows itself as NaN, and other times, it's a mismatch in values. These happen when:

• NaN: whenever a timezone is missing from the tzToOffset hash . An example is ALMT.
• mismatch: whenever a timezone offset is incorrect. YAKT is actually -600, not -540.

Perhaps related to this are failures of test time intervals: AssertionError: ["1 year","1 day"] deepEqual ["1 year","2 days"].

I'm looking at http://www.iana.org/time-zones and seeing about generating an updated offset hash.

[taketime]

Hmm, there's a problem with tzToOffset: sometimes the same abreviated timezone refers to more than one actual timezone. Example: CST can be North American Central Standard Time (GMT-6). CST can also be Australian Central Standard Time (GMT+9:30). This is the case in OS X at least. I'm thinking of other options.

[taketime]

The format problem:
When trying to format without a timezone, currently we try to find the abbreviated timezone from Date().toSting(). This results in a timezone like 'CST', which could be any of
* china standard time (GMT+8)
* central australian standard time (GMT+9:30)
* central standard time (the US one) (GMT-6)

This abbreviated timezone is looked up in the tzToOffset hash, which returns an offset in minutes from GMT.

The solution here appears to be skipping the failing lookup, and just get the offset right away (like in https://github.com/kkaefer/chrono.js/blob/master/lib/chrono.js#L387). I'm unsure if there's a use in the regex for checking for the string.

[willwhite]

Nice find.

When trying to formate without a timezone

What does this mean exactly? Would we avoid this problem by setting a timezone? Should we be setting a timezone?

[taketime]

@willwhite I've been attacking this by running the tests, and a format test has been among the consistent failures.

Next steps are:

• fix occasional test failures in the timezone intervals tests
• see if f9ad00c fixes the problem on local invoices (while moving around timezone on my machine). Update: this appears to fix the problem locally. I'm waiting on @kkaefer's comment on my PR. I tested by switching to a timezone not in the timezone lists, like ALMT (East Kazakhstan time). No NaN issues.

[taketime]

Tracking additional test failures in #12