Double check that I'm handling time zones right

Question

Double check that I'm handling time zones right

Closed this issue 5 years ago · 12 comments

@potash maybe you could help me make sure all my time zones are in line. The NWS uses UTC for its timestamps, right?

Answer 1 · 2020-02-21T18:00:51.000Z

Other assumption: Defining a day as 6pm-6pm Chicago time means that I only need to pull the UTC sheet from the current day, as the timezone offset is 6 hours.

Answer 2 · 2020-02-21T18:14:34.000Z

be careful, its UTC-6 now but it'll be UTC-5 in a couple of weeks (daylight savings)!

…

---- On Fri, 21 Feb 2020 12:00:51 -0600 Bea Malsky <notifications@github.com> wrote ---- Other assumption: Defining a day as 6pm-6pm Chicago time means that I only need to pull the UTC sheet from the current day, as the timezone offset is 6 hours. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Answer 3 · 2020-02-21T18:19:12.000Z

dang! good point!

Answer 4 · 2020-02-21T18:19:34.000Z

time zones are truly the hardest problem in computer science

Answer 5 · 2020-02-21T18:53:51.000Z

Sorry I now see your question about whether NWS uses UTC. The NWS uses timestamps in two places: the start and end params of URL of the request you make and in its response. The response timestamps look like this: 2020-02-21T17:51:00+00:00note the +00:00 this is the UTC offset, which is zero, so it is in UTC. If you use this format (whatever ISO it is, its probably the default string format for a pandas Timestamp?) for the start and end params the timezone is always explicit so there should be no issues.

Answer 6 · 2020-02-21T18:57:18.000Z

So you do everything in UTC except when printing the date in the tweet (if you do this?). At that point you use the America/Chicagotimezone (which includes daylight savings when appropriate) in your date format call. This is how we do it on the website and it should be pretty error free.

Answer 7 · 2020-02-21T20:28:54.000Z

Gotcha. I noticed and like this general principle of keeping everything in UTC times other than what's printed out to the user!

To that end, maybe it makes sense to think in these terms: instead of 6pm-6pm CT, this bot is simply looking at 12am-12am UCT each day. That means that we don't have to worry about daylights savings, and it syncs beautifully with the Heroku scheduler, which I'm using the time the tweets right now. It currently runs every day at 12am UTC and looks at the last 24 hours of data. It means that it will tweet at a different local time depending on whether or not it's daylight savings, but I'm not too bothered by that. Wdyt?

Answer 8 · 2020-02-21T20:44:06.000Z

Looking ahead to other cities in other timezones (which I would also like to deploy twitter bots for), I think it makes sense to pick a fixed local time. I don't know anything about Heroku's scheduler but in the worst case you could have the bot run every hour and first thing it does is check whether its 6pm local time in whatever zone. In fact if its later a single bot for many cities, that'll probably be the right way to handle it (though you could also do separate bot for each city): wake up every hour, check which cities its currently 6pm in and proceed to tweet for those cities. Wdyt?

…

---- On Fri, 21 Feb 2020 14:28:55 -0600 Bea Malsky <notifications@github.com> wrote ---- Gotcha. I noticed and like this general principle of keeping everything in UTC times other than what's printed out to the user! To that end, maybe it makes sense to think in these terms: instead of 6pm-6pm CT, this bot is simply looking at 12am-12am UCT each day. That means that we don't have to worry about daylights savings, and it syncs beautifully with the Heroku scheduler, which I'm using the time the tweets right now. It currently runs every day at 12am UTC and looks at the last 24 hours of data. It means that it will tweet at a different local time depending on whether or not it's daylight savings, but I'm not too bothered by that. Wdyt? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Answer 9 · 2020-02-24T17:14:45.000Z

I've been thinking about how to best extend this for other cities too! It's set up to be easily extended for any place in the stations.csv file.

I think the best way to organize that will be a different Heroku app using this same repo for each bot. CITY can be defined in a Heroku environment variable instead of here, meaning that the process of setting up a new bot will be making the Twitter account, generating the necessary API keys (these things, which I believe need to be unique to each Twitter account), and setting up a new app in Heroku with the necessary scheduled job.

Which is all to say that I think your idea of checking every hour to see if it's 6pm local time makes a lot of sense. The tricky part for me is making sure I'm pulling in the historical data right, time zone wise, so let me give it a shot and then it'd be great if you could check my handling.

Answer 10 · 2020-02-24T18:23:34.000Z

Sure let me know when you have something you want me to review. Reasons to consolidate I can think of are if there are limits on free deployment and also i would think it's simpler to manage a single app than 20 but there are advantages to one bot per city too so I trust your judgment and it's not set in stone

…

---- On Mon, 24 Feb 2020 11:14:46 -0600 notifications@github.com wrote ---- I've been thinking about how to best extend this for other cities too! It's set up to be easily extended for any place in the stations.csv file. I think the best way to organize that will be a different Heroku app using this same repo for each bot. CITY can be defined in a Heroku environment variable instead of here, meaning that the process of setting up a new bot will be making the Twitter account, generating the necessary API keys (these things, which I believe need to be unique to each Twitter account)), and setting up a new app in Heroku with the necessary scheduled job. Which is all to say that I think your idea of checking every hour to see if it's 6pm local time makes a lot of sense. The tricky part for me is making sure I'm pulling in the historical data right, time zone wise, so let me give it a shot and then it'd be great if you could check my handling. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Answer 11 · 2020-02-24T19:37:46.000Z

Are you imagining that the same Twitter account would handle multiple cities, or are we still talking about backend setup?

Answer 12 · 2020-02-24T21:30:33.000Z

backend setup, one account per city

…

---- On Mon, 24 Feb 2020 13:37:47 -0600 Bea Malsky <notifications@github.com> wrote ---- Are you imagining that the same Twitter account would handle multiple cities, or are we still talking about backend setup? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.