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

Tasks will fail when settings.USE_TZ = False #8

Open
ryanbagwell opened this issue Aug 18, 2014 · 7 comments
Open

Tasks will fail when settings.USE_TZ = False #8

ryanbagwell opened this issue Aug 18, 2014 · 7 comments

Comments

@ryanbagwell
Copy link

By default, the Django setting USE_TZ = False. This will throw errors when running tasks because this reference to the current time is not timezone aware.

The tests pass because they're bypassing the task running command.

I'm not sure what the best way to handle this is. My thought is that we should require USE_TZ to be True for consistency, and if it's not, throw an assertion error with a clear explanatory message.

I created an additional test in order to test the runner task. It's in a branch tz-issues.

@matthewwithanm
Copy link
Contributor

According to this SO question, timezone.now() is supposed to respect USE_TZ and return a timezone-aware datetime. Is the problem that it's always UTC?

@ryanbagwell
Copy link
Author

From the Django docs for timezone.now():

If USE_TZ is False, this will be a naive datetime (i.e. a datetime without an associated timezone) that represents the current time in the system’s local timezone.

If USE_TZ is True, this will be an aware datetime representing the current time in UTC. Note that now() will always return times in UTC regardless of the value of TIME_ZONE; you can use localtime() to convert to a time in the current time zone.

By default, USE_TZ = False, which means by default, timezone.now() will not return an aware datetime.

@matthewwithanm
Copy link
Contributor

Oh, so the issue is that a time generated elsewhere is timezone aware, mucking up the comparison?

@ryanbagwell
Copy link
Author

Exactly. Here's the first culprit.

@matthewwithanm
Copy link
Contributor

Where's the date that one's being compared to? Also, can you paste a stacktrace?

@ryanbagwell
Copy link
Author

The schedule class is where the comparison object is made timezone aware.

The comparison is happening in the time_before method of the schedule class.

The time_before() method gets called in utils.get_scheduled_time() which passes the unaware datetime object.

utils.get_scheduled_time() is called by backends.BaseBackend._run_tasks(), which is where the unaware datetime is created.

@matthewwithanm
Copy link
Contributor

Ah, so maybe we should only make this guy timezone aware if settings.USE_TZ?

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

No branches or pull requests

2 participants