Skip to content

Default timezone should be 'Z' not 'local' (broken test) #360

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
grncdr opened this issue Dec 15, 2012 · 1 comment
Closed

Default timezone should be 'Z' not 'local' (broken test) #360

grncdr opened this issue Dec 15, 2012 · 1 comment

Comments

@grncdr
Copy link
Contributor

grncdr commented Dec 15, 2012

Given that MySQL can't store timezones with datetime columns, and that the common wisdom is to store everything in UTC, the default connection config should be 'Z' and not 'local'. There should probably also be a big warning in the docs about how using timezone = 'local' can cause problems.

As an example of how the 'local' default can cause subtle bugs, the file test/integration/connection/test-type-casting.js contains the following test case:

{type: 'date', insert: new Date('2012-05-12 00:00:00 Z')}

Because the test connection is using the 'local' timezone, this test fails if you are in a timezone with a negative UTC offset. The date will be formatted by SqlString.escape as '2012-05-11 $time', and stored in mysql as '2012-05-11'. When it's retrieved it's parsed as new Date('2011-05-11'). Because there is no time part to the date it's treated as UTC, meaning you end up with a date exactly 24 hours off.

Setting connection.config.timezone = 'Z' "fixes" the test.

@dresende
Copy link
Collaborator

Being discussed in #361.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants