Skip to content
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

Sync/update must be timezone-agnostic #77

Closed
julen opened this issue Nov 8, 2016 · 0 comments
Closed

Sync/update must be timezone-agnostic #77

julen opened this issue Nov 8, 2016 · 0 comments
Assignees
Labels

Comments

@julen
Copy link
Contributor

julen commented Nov 8, 2016

We recently hit a bug in update/sync where the code was failing to run due to an ambiguous datetime. This happened because a) the server clock switched away from DST, and b) pytz is now available.

What this outlined is that for unknown reasons update/sync is converting timestamps into timezone-aware datetime objects. Since unix timestamps work perfectly fine in this scenario, so the conversion is unnecessary.

@julen julen added the bug label Nov 8, 2016
julen added a commit to julen/zing that referenced this issue Nov 5, 2018
Apart from not being necessary or efficient, using local time for this
purpose is buggy when there are files on disk that changed during DST
adjustment periods.

Therefore from now on `Store`'s `file_mtime` field will be an integer
holding the unix timestamp value.

Fixes serge-community#77.
julen added a commit to julen/zing that referenced this issue Nov 5, 2018
Apart from not being necessary or efficient, using local time for this
purpose is buggy when there are files on disk that changed during DST
adjustment periods.

Therefore from now on `Store`'s `file_mtime` field will be an integer
holding the unix timestamp value.

Fixes serge-community#77.
julen added a commit to julen/zing that referenced this issue Nov 5, 2018
Apart from not being necessary or efficient, using local time for this
purpose is buggy when there are files on disk that changed during DST
adjustment periods.

Therefore from now on `Store`'s `file_mtime` field will be an integer
holding the unix timestamp value.

Fixes serge-community#77.
@julen julen closed this as completed in #360 Nov 5, 2018
@julen julen self-assigned this Nov 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant