This is another fairly boring article, as I am trying to reduce the cost of doing something boring but is an important responsibility. For some background reading, I reference 1 2 3.
For older projects, all date manipulation was done on server-side; where I can easily control the timezone. This means I can write unit tests that execute “in a different TZ” to the current real world. In PHP its a config setting 4, which can be injected at runtime. Similarly in Perl, it can be set 5 with an @ENV variable. Solution for Python, resembles Perl 6, for comparison of timezones, use 7. With Node, the TZ can be set 8, but only once, as the results are cached inside Node. The above are trivial, and not worth the effort of writing an article about. It should be also noted, that most normal servers run in UTC TZ all year, so shifting TZ is needed to normalise dates that have been sent in an encoding.
With fat client applications, features are executed on the client side, in JS. As JS is a restricted environment, with intentionally less access to the system; features like setting the timezone are not available. Timezones do shift during the year; your product may be used in different country to where it was made; and not all timezones are full hours. The basic objective of this article is to be able to efficiently test random values for the timezones; including the client not having the same timezone as the server. In my current projects, the TZ isn't a user input, there is no attention to TZ locale parsing eg 9.
The Date object in JS (either node or browsers) doesn't support setting the TZ 10 11. There are hacks that give the effect of setting the TZ 12, but these are hacks. If you are constrained to using ms-windows, the following is more useful 13. As a non-hacky solution, it is possible to set how the rendering of Dates works with DateTimeFormat? 14. Scroll to the end for a chart of current browser compatibility. Moment.js 15, as ever, is a huge library packed with features, including management of TZ. I also found a list of other libraries 16, but this list was written in 2013.
I assert that for testing, I am using a Node process for JS; which is much easier to automate. This can't be used for everything, in particular QA e2e tests ~ as Node has a different release cycle to browsers (so tests may pass, but the service would fail for consumers). For the e2e tests, a Chrome instance can be setup with a custom TZ. Chrome reads the TZ env variable, just like Node 17. The link is for ms-windows, the script is much simpler unde a Linux.
What I build is:
- A unit test with what a “happy path” client would see is a normal TZ, sending data to the UTC server. The networking class is to swapped with a logging class, and the sent data checked to expectations. My APIs tend to transmit dates as Epoch ints as the client configuration will be different for each client.
- A unit test for server responses, with what a “happy path” client would expect to receive for TZ (this should match the above). This unit is to confirm the client-side software renders the dates back into the “happy path” TZ.
- Two unit tests for the “other season”, ie Summer time TZ.
- Two unit tests for a different starting locale
- Two unit tests for an awkward size TZ, e.g. 30min like Asia/Calcutta, which is 05:30 offset.