Ability to set local timezone would be really handy

[createthis]

I've been using timekeeper for years. It works great most of the time, but every now and then I run into a bug that is only reproducible by changing the local timezone. Timekeeper doesn't appear to have an ability to do that. There are a couple of other packages out there that do. One named chronokinesis seems interesting, but doesn't appear to be very popular. It appears to have the same API as timekeeper, but also has a timezone capability: https://github.com/paed01/chronokinesis#timezonetimezone

I don't know if it works or not. The only way I know to manipulate the local timezone is via environment variables:

const old_tz = process.env.TZ;
process.env.TZ = 'UTC';
// do stuff
process.env.TZ = old_tz;

Manipulating environment variables in tests is less than ideal due to shared state issues.

Can we get similar functionality in timekeeper?

[freewil]

can you provide a code example that shows the issue you're running into? I suspect you may be handling Dates in a less than best-practice way.

I would not recommend overriding the system's timezone with TZ - I've seen this used in large applications and it is usually always a hack/workaround from improperly understanding how to handle timezones correctly.

timekeeper works on JS's Date object, which is based on UTC (the timezone of the system is typically used for displaying dates but there are ways to display in UTC Time).

A JavaScript date is fundamentally specified as the number of milliseconds that have elapsed since midnight on January 1, 1970, UTC.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date

If you need something higher-level to deal with timezones, you may want to use a library like moment.js. You can then use the toDate() method to go from a moment.js object to a normal JS Date object for uses with timekeeper.

[createthis]

You may be missing my point. I write unit tests using timekeeper precisely so that I can ferret out cases where I or another team member has somehow screwed up the code. If there is a bug, I need to be able to reproduce it by writing a unit test before I can fix it, per my team policy. If the bug only appears when I change the timezone, then I have to change the timezone in order to reproduce the bug.

[createthis]

The latest instance of this, for me, is a bug I'm working on where a former teammate introduced a unit test that fails in the Eastern timezone, but passes in UTC. It appears to be something having to do with sequelize's handling of the date object in the where clause.

When I have a mysql DATEONLY field in sequelize, these are the queries it generates for the same date object in the America/New_York timezone:

process.env.TZ = 'America/New_York';

calendar_day= 2019-10-21 , calendar_day_as_local_date= 2019-10-21T00:00:00.000Z { constructor: [Function: Date] }
Executing (default): SELECT `int_business_day` FROM `business_days` AS `business_days` 
WHERE `business_days`.`calendar_day` = '2019-10-20' LIMIT 1;

And the UTC timezone:

process.env.TZ = 'UTC';

calendar_day= 2019-10-21 , calendar_day_as_local_date= 2019-10-21T00:00:00.000Z { constructor: [Function: Date] }
Executing (default): SELECT `int_business_day` FROM `business_days` AS `business_days` 
WHERE `business_days`.`calendar_day` = '2019-10-21' LIMIT 1;

You can see my date object calendar_day_as_local_date is the same in both cases, but I get totally different calendar_day WHERE clauses.

The solution here is pretty simple. I just use moment to create the date instead of the date constructor. moment does the right thing in both timezones. However, I have to write tests for both timezones proving my solution works.