Timezone from operating system not working as expected

[dirkvanrensburg]

Hi,

Upgrading crontab to 0.21.x from 0.20.x caused problems in my script. My timezone is Australia/Sydney.

System details:

Ubuntu 14.04
Python version: 2.7.6

I used the following script to illustrate the problem:

t.py

import datetime
from crontab import CronTab

print 'Local date:', datetime.datetime.now()

c = CronTab('* 9-17 * * MON-FRI')

print c.next()

On version 0.20.5

me@server:~/tmp$ date
Wed Apr 20 15:21:13 AEST 2016
me@server:~/tmp$ python t.py
Local date: 2016-04-20 15:21:14.964162
45.035433

On version 0.21.3

me@server:~/tmp$ date
Wed Apr 20 15:22:23 AEST 2016
me@server:~/tmp$ python t.py
Local date: 2016-04-20 15:22:25.686065
13054.313699

Thanks

Dirk

[josiahcarlson]

Times produced by datetime.datetime.now() only "worked" with previous versions of crontab in the sense that they were fortunate enough to fall through a path of bugs to ultimately result in "usually correct" results. That path of bugs has been removed, though the fallthrough behavior was supposed to remain. I had intended for bare .next() calls to spew a warning message of the future change in semantics, but due to a bug, that future change became now, and the warning was never produced for bare .next() calls (the warning would have been produced with a passed-in datetime without a timezone, or a bare numeric timestamp). The warning should look like:

Local date: 2016-04-20 10:16:25.540500
t.py:8: FutureWarning: Version 0.22.0+ of crontab will use datetime.utcnow() and
datetime.utcfromtimestamp() instead of datetime.now() and
datetime.fromtimestamp() as was previous. This had been a bug, which will be
remedied. If you would like to keep the *old* behavior:
`ct.next(..., default_utc=False)` . If you want to use the new behavior *now*:
`ct.next(..., default_utc=True)`. If you pass a datetime object with a tzinfo
attribute that is not None, timezones will *just work* to the best of their
ability. There are tests...

In any case, if you want to preserve your old behavior for now, you can use c.next(default_utc=False). But if you want to do yourself one better, pass datetimes in with a timezone attached; then you'll get DST change-aware schedules.