Solving the problem with failing tests across (some) timezones

[ichernev]

Currently there is the grunt zones command, that would do some hacky (works only on mac with sudo privileges) stuff to run all tests in all timezones. It takes ages and it shows many failing tests (37 on my machine at the moment).

Fixing those is super tedious and normally involves a date being used in a test, that is near or at a DST. So the fix is sometimes changing to a different date and hoping there is no DST of another timezone there. Sometimes there is no easy fix (America/Havana failing because of DST exactly at the beginning of the month).

From time to time such issues pop up as issues in the tracker, but its hard to debug because I don't know which zone are they in (not the offset, but the rules that govern the offset), so I can not replicate it on my linux box (in node environment).

I think we need to either run this tests as part of our continuous build, so that we know all tests past in all timezones all the time (we can use TZ="America/Los_Angeles" grunt nodeunit to run tests without changing the actual OS timezone), or we can implement a way of marking certain timezone/test combinations as bad, and not caring/running the test at all. The second solution sounds bad, but I really don't want to care about some obscure DST happening 30 years ago when I'm writing a random moment test, that is not concerned about DST at all.

[icambron]

The single biggest problem remaining here is tests that fail when the current time is near a DST. See especially the calendar() tests, which verify, for example, that today minus 7 days is "last Saturday". If there's a DST in there, the subtraction gets mixed up. These are really hard to manage, because they fail sometimes in some places.

[WesleyBlancoYuan]

To check the rules, maybe you can use some external libs or check https://www.timeanddate.com/time/change ? For the limited examples I have checked, it works well. (Madrid, Vienna, Sao Paulo)