[16:07:26] <jaraco> leetrout: I used to think the same - we should all switch to UTC, but then I realized that doesn't solve the time issues either. If everybody switched, then we would have to keep track of what time "things happen" such as what is a reasonable time for work to start in California versus Texas.
[16:07:31] <j00bar> but the 24 hour period is midnight-to-midnight local to the timezone of the ad account's user adjusted to utc
[16:07:49] <rzoz> j00bar: that's similar to what we have
[16:10:09] <j00bar> no - if you ask facebook for the stat from 4am to 4am march 10, 2012, and then try to get the stats for the next day by adding timedelta(days=1), facebook gives you the stinkfinger
[16:10:52] <rzoz> we have tables of time zone changes which are helpful, but the data are broken too in a way. i have this beautiful foo.convert(airport, datetime) method to which i will now have to add a foo.convert_as_if_it_were_still_midnight_or_something_awful_like_that(airport, datetime)
[16:11:50] <rzoz> i don't understand why this particular data set is in local time. everything else we get from faa is zulu.
[16:11:58] <j00bar> yeah, and we have all of these awful "what day is it and what time does its stats start?" functions where we have to take the local time gmt, adjust it to the local timezone, drop the time part to get the date, add 00:00:00 local, and adjust to utc
[16:12:47] <j00bar> because today's stats at 1am utc for east coast accounts are actually the previous day's (from utc's perspective)
[16:13:19] <j00bar> demonstration #9512 of how facebook's api is super helpful