Timezone-induced test failures on CI
See original GitHub issueWhen updating #361, I experienced an odd issue – a few tests were failing on master (not my own branch!) for no clear reason. Here’s the summary:
Summary of all failing tests FAIL test/en/en_relative.test.ts (9.746 s) ● Test - Relative date components’ certainty
expect(received).toBe(expected) // Object.is equality Expected: -240 Received: -300 155 | expect(result.start.get("day")).toBe(7); 156 | expect(result.start.get("hour")).toBe(12); > 157 | expect(result.start.get("timezoneOffset")).toBe(refDate.getTimezoneOffset() * -1); | ^ 158 | 159 | expect(result.start.isCertain("year")).toBe(true); 160 | expect(result.start.isCertain("month")).toBe(true); at test/en/en_relative.test.ts:157:52 at Object.<anonymous> (test/en/en_relative.test.ts:151:5)
● Test - Relative date components’ certainty and imply timezone
Expected date to be: Mon Nov 30 2020 11:00:00 GMT-0500 (GMT-05:00) Received: Sun Nov 29 2020 11:00:00 GMT-0500 (GMT-05:00) ([ParsingResult {index: 0, text: 'tomorrow at 5pm', ...}]) 186 | result.start.imply("timezoneOffset", 60); 187 | > 188 | expect(result).toBeDate(new Date("Sun Dec 1 2020 1:00:00 GMT+0900 (Japan Standard Time)")); | ^ 189 | expect(result).toBeDate(new Date("Sun Nov 30 2020 17:00:00 GMT+0100")); 190 | } 191 | at Object.<anonymous> (test/en/en_relative.test.ts:188:24)
This is current master
, which is at commit 6daa27d
. I’m on Node v14.15.1
.
Most oddly, I rebased PR #361 on top of that commit, and didn’t make any changes that should affect tests, but they pass on Travis instead of failing.
Issue Analytics
- State:
- Created 3 years ago
- Comments:8 (6 by maintainers)
Top Results From Across the Web
Why Do My Tests Pass Locally but Fail on CircleCI?
Some testing frameworks may not have timezone-aware modules. If the machine does not have a set timezone, some tests may fail.
Read more >How to reduce test failures in CI\CD pipelines? - Testomat.io
In this article, we'll talk about fixing test scripts that somehow failed on your CI server. We'll also cover why it's vital to...
Read more >CICD - How To Resolve Failing Tests - Undo.io
How to make software application test failures in CI go away using LiveRecorder for debugging and rapid error resolution. Use time travel debugging...
Read more >Why my date formatters test fails in CI and passes locally?
The story of debugging date time formatting issue. It passes locally, it fails on CI. How can it be?
Read more >Troubleshooting Continuous Integration, or How to Debug ...
Don't Relaunch the CI Build. If the tests failed once on the CI, they will probably fail again - unless you change the...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Yep, fragile test assertion. First one mentioned above is fixed in #368.
With
refDate
as normalDate
object, the refDate’s timezone information will be lost and we cannot really calculate the precise relative time without assuming it’s the same timezone as the system. Maybe in the future major release we should let people pass refTimezone or refDate as string.For now, I am thinking we should remove that close to mid-night checking logic (minor release 2.2+). I don’t really think that logic is that helpful anyway. I’ll do that sometime this weekend.
Please let me know what you think.