UTC

[Dariusz Suchojad]

Hi,

I'd like to return to the discussion started last year over here
https://groups.google.com/forum/?fromgroups#!topic/apscheduler/X83R7HDhP20[1-25]
regarding UTC.

There were two reasons listed for APScheduler's not using UTC.

1) No tzinfo classes for working with timezone-aware datetime objects
2) Lack of support for time zones in database backends

I'd like to understand why these two need to get into the way of using
UTC by default.

My use case is that I have several instances of an application running
in different time zones with a load-balancer in front of them and the
application already uses UTC everywhere internally except when
displaying date and time to users which is the only moment when UTC gets
converted to the user's local time zone.

This is all good except that the operating systems the code that uses
APScheduler is running on would've need to use UTC as well because
APScheduler doesn't use datetime.utcnow() instead of datetime.now() when
it wants to grab the current time.

This would've been mostly OK however there are situations when it causes
confusion, e.g. when the application is run on a developer's laptop that
happens not to be using UTC for various reasons.

So I'd like to propose making APScheduler optionally use UTC only and I
just can't understand why the two points above should cause any problems.

Ad 1) No time zone-aware would be needed if APScheduler assumed every
datetime object it received or produced was always UTC and if it started
using .utcnow() in place of .now()

Ad 2) This isn't particularly to do with APScheduler as such but a
standard practice is simply to always store UTC in the database. That
is, discard the time zone part unless it is needed later on. I believe
APScheduler wouldn't need this information for anything so it could just
use UTC in databases by default - meaning it could use, say, TIMESTAMP
WITHOUT TIME ZONE in Postgres.

So in short, APScheduler's not using UTC makes it difficult to use when
multiple time zones are involved and unless I'm missing something
obvious, there shouldn't be any time zone-related stuff needed if
everything was (optionally) UTC everywhere.

cheers,

--
Dariusz Suchojad

[Michel Samia]

I have the same problem and I absolutely agree with Dariusz, only UTC should be saved to DB and all objects

Dne středa, 15. srpna 2012 17:07:23 UTC+2 Dariusz Suchojad napsal(a):