make datetime objs timezone-aware and UTC default

[sarnold]

• requires (assumes) standard config of local system and hw clocks
  (everything is UTC by default using system TZ offset)

After looking through several timezone-related PRs/issues, I think a simple UTC time config is probably the safest default, although it does rely on the system timezone being set. That said, current Linux distros, modern Linux kernels, NTP, etc, are pretty standard. Use as you see fit.

[coveralls]

Coverage decreased (-6.4%) to 93.56% when pulling fa01b4b on sarnold:utc-time into 41f88b3 on dbader:master.

[sarnold]

Hmm, the tests run here fine, and travis seems happy except for 2.7 where it bails with an import error building docs. Got any tips for that?

[SJLC]

If you're going to always use utc for timezone, how about datetime.datetime.utcnow() in place of datetime.datetime.now(timezone.utc)

[sarnold]

I think I'm pretty much done with this one (pending feedback). Thanks for making me update/add tests and learn something new... ;)

[sarnold]

Hmm, this looks okay now, albeit with some extra functionality and reworked tests. Let me know if you'd rather have some squashing and/or more separation.

[sarnold]

Note this is no longer just the timezone-awareness after the recent rebase; it now includes a few extra "features" like a tag parameter and some new job properties. Also includes new tests for the above and green builds on linux/os/x and all the python versions.

[sarnold]

Current totals are:

----------- coverage: platform linux, python 3.7.1-final-0 -----------
Name                   Stmts   Miss  Cover   Missing
----------------------------------------------------
schedule/__init__.py     274      4    99%   42-43, 462-466

26 passed in 0.93 seconds =====================

versus:

----------- coverage: platform linux, python 3.7.1-final-0 -----------
Name                        Stmts   Miss  Cover   Missing
---------------------------------------------------------
schedule/__init__.py          304      7    98%   42-43, 54-56, 508-512
schedule/parent_logger.py       8      0   100%
schedule/timezone.py           12      3    75%   13, 16, 19
---------------------------------------------------------
TOTAL                         324     10    97%

35 passed in 1.17s ==========================

[kmcminn]

came here because I was looking for an explicit way to define the timezone.
as a user I would like to specify the option (explicit timezone or server timezone).

couple nits:

• use pytz instead of timezone.utc (more sustainable, also to support user defined timezone)
• datetime.datetime.now(timezone.utc) is the correct way to get utc in python (utcnow() is naive)

besides this it lgtm

[gogognome]

When will this branch be merged? We need it because it probably fixes the problem we had during the ending of Daylight Saving Time: we schedule jobs to run every minute, but for one hour no jobs are executed because the local time is changed from 3:00 to 2:00.

[samgermain]

If you're going to always use utc for timezone, how about datetime.datetime.utcnow() in place of datetime.datetime.now(timezone.utc)

datetime.utcnow() is suppossed to be worse than datetime.now(timezone.utc)

[samgermain]

Yeah can you merge this? I'm trying to schedule something, and can convert the time so that it matches the correct utc time, but I think daylight savings will mess it up

[sarnold]

My new PR #489 is an attempted re-work of this one; if someone could test it, that would be super-helpful. Note my particular need (at the time) was reasonable UTC log times for long-running/daemonized scheduler. Hopefully that still fits someone else's need, otherwise the answer is basically a fully-tzaware scheduler with default/per-job tz attributes (give or take the logging setup).