I have little visibility on the requirements of the community around making Airflow timezone aware as I have an internal UTC clock in my brain. For the record some of the engineers here answer in UTC when casually asking "what time is it?" ):
I'd be interested in reading a proposal / impact analysis on the subject though. Max On Tue, Jun 7, 2016 at 5:26 AM, Eric Johnson <[email protected]> wrote: > Where is the flaw in this thinking? > > So if airflow consistently uses naive datetime objects, won't they all end > up using the same timezone and thus be equally right in the same kind of > wrong way? I would only anticipate a problem when there is a mismatch when > comparing a naive datetime object with a timezone aware datetime object. > But that doesn't seem to be the case here. > > I'm not trying to ignore the wisdom offered from others about embracing UTC > everywhere especially given the pains daylight saving time. It's just that > this requirement can be a bit of an imposition for some of us who are > trying to embrace airflow in an environment where its not UTC everywhere. > So my line of questioning is aimed at trying to suss out just what breaks > when you use another timezone. > > -Eric > > On Mon, Jun 6, 2016 at 7:10 PM, George Leslie-Waksman < > [email protected]> wrote: > > > There are three common ways of handling timezones: 1) use timezone aware > > datetime objects, 2) use timezone naive datetime objects and make sure > any > > system running your software has its clock set toUTC, or 3) be very, very > > sad because have potentially inconsistent times in your logs, scheduling, > > etc. > > > > Airflow uses timezone naive datetime objects everywhere so you're stuck > > with option 2 or option 3. > > > > Historically, handling timezones has been a pain so most people try to go > > with option 2. I would argue that it's gotten easy enough in Python that > it > > would be worth moving airflow to timezone aware datetime objects and > making > > everything a little bit easier/safer from a DevOps perspective. > > > > On Mon, Jun 6, 2016 at 2:50 PM Lance Norskog <[email protected]> > > wrote: > > > > > Any larger use of log management will end up with servers in two > > different > > > time zones. The ops team will inevitably set all machines to run with > > time > > > zone UTC. After that, all of the logs will be in UTC. > > > > > > > > > > > > On Mon, Jun 6, 2016 at 9:49 AM, Edwards, Jesse <[email protected] > > > > > wrote: > > > > > > > While I can't speak to Airflow's exact requirement. > > > > > > > > > > > > For me the really clear reason is: > > > > > > > > > > > > 1. All other timezones are based off UTC +/- some amount. Thus > > > calculating > > > > the time in any given timezone is trivial. > > > > > > > > 2. UTC does not have daylight savings! It really sucks and throws > > systems > > > > out of whack when they think there are two 2AM hours on Time change > =). > > > > > > > > > > > > Jesse > > > > > > > > ________________________________ > > > > From: Eric Johnson <[email protected]> > > > > Sent: Monday, June 6, 2016 9:28:54 AM > > > > To: [email protected] > > > > Subject: UTC everywhere requirement > > > > > > > > Hi - > > > > > > > > I see that at the moment Airflow wants everything to be in UTC. > > > > > > > > Can those who understand this requirement speak a bit about where in > > the > > > > code this dependency exists? I took a cursory glance through the code > > in > > > a > > > > brief attempt to understand the scope of this issue and it wasn't > > > > immediately obvious where this was even assumed. I don't doubt it. > Just > > > > didn't spot it. > > > > > > > > I can certainly understand the need for all of airflow to run in the > > same > > > > time zone. But I find it odd that it really needs everything to be > UTC > > > and > > > > only UTC. > > > > > > > > Eric > > > > > > > > > > > > > > > > -- > > > Lance Norskog > > > [email protected] > > > Redwood City, CA > > > > > >
