I collect the users city on my site using gps/browser location opt in, or by autocomplete against google locations.
Has anyone figured out a way for me to get the users timezone from their city?
Why You Should Use Timezone Offsets Not Timezone Names
21–30 of 51 posts
Re: Why You Should Use Timezone Offsets Not Timezone Names
#22I collect the users city on my site using gps/browser location opt in, or by autocomplete against google locations. Has anyone figured out a way for me to get the users timezone from their city?
Google has a timezone API: https://developers.google.com/maps/documentation/timezone/in...
Re: Why You Should Use Timezone Offsets Not Timezone Names
#23The political realities of timezones is _exactly why_ you should be storing the timezone name if the user is scheduling it for an event in their local timezone. If a user is expecting an event to happen at 6pm in their local timezone, and political reasons cause that timezone's offset to change (ie. daylight savings), it will still happen at the correct local time for that user. Storing UTC offsets means that any fut…
I wish they could at least store it in terms of the timezone name, like "Central Time". "America/Chicago" bothers me because I don't know what cities are and aren't in your timezone database. The ones that have a tiny map that you have to click on are also pretty bad.
https://www.iana.org/time-zones
"America/Chicago" is a standard timezone name.
Re: Why You Should Use Timezone Offsets Not Timezone Names
#24Earlier quoted context omitted.
I wish they could at least store it in terms of the timezone name, like "Central Time". "America/Chicago" bothers me because I don't know what cities are and aren't in your timezone database. The ones that have a tiny map that you have to click on are also pretty bad.
CST is not the same thing as America/Chicago. If you say CST you specifically do not mean daylight savings time, which is CDT.
And more commonly, EST doesn't mean just Eastern.
Re: Why You Should Use Timezone Offsets Not Timezone Names
#25The political realities of timezones is _exactly why_ you should be storing the timezone name if the user is scheduling it for an event in their local timezone. If a user is expecting an event to happen at 6pm in their local timezone, and political reasons cause that timezone's offset to change (ie. daylight savings), it will still happen at the correct local time for that user. Storing UTC offsets means that any fut…
I wish they could at least store it in terms of the timezone name, like "Central Time". "America/Chicago" bothers me because I don't know what cities are and aren't in your timezone database. The ones that have a tiny map that you have to click on are also pretty bad.
I think one of the reasons "Country/City" is used is due to variances within a timezone. Take Mountain Time, for example. "America/Denver" is different from "America/Phoenix" due to Arizona not observing daylight savings time. So in the middle of summer, America/Denver will translate to MDT while America/Phoenix will be MST.
(And I may be further proving your point if Denver isn't the landmark city, I'm just guessing!)
Re: Why You Should Use Timezone Offsets Not Timezone Names
#26Earlier quoted context omitted.
I think the main thing to remember is that dates and times have very different semantics when used for different purposes. If you are referring to an instant in time, then just using UTC is reasonable. If you are referring to a past event and both the local time and precise instant are relevant, then the local time with a timezone offset is reasonable. If you are scheduling events on a calendar, however, like "8 AM e…
TZDATA ships with historical timezone information, so using the timezone name should also work for past events, no?
It does, there is no reason to translate to fixed offsets for past events.
Re: Why You Should Use Timezone Offsets Not Timezone Names
#27The political realities of timezones is _exactly why_ you should be storing the timezone name if the user is scheduling it for an event in their local timezone. If a user is expecting an event to happen at 6pm in their local timezone, and political reasons cause that timezone's offset to change (ie. daylight savings), it will still happen at the correct local time for that user. Storing UTC offsets means that any fut…
Which is why you are both right: Offsets are good for past events, time zones for future ones. It's a real pain to deal with..
If you're using the Olsen Database[0], aren't past (and future) changes all handled properly?
[0] https://en.wikipedia.org/wiki/Tz_database
See: Example zone and rule lines
Re: Why You Should Use Timezone Offsets Not Timezone Names
#28I just DONT want to deal with time EVER. It's such a mess. Can't we just.. i don't know. throw away the current system and actually build something that a programmer can understand? Who counts to 24 and 60 anyway?
Re: Why You Should Use Timezone Offsets Not Timezone Names
#29Tom Scott talking about timezones and it's quirks: https://www.youtube.com/watch?v=-5wpm-gesOY
Re: Why You Should Use Timezone Offsets Not Timezone Names
#30Earlier quoted context omitted.
I wish they could at least store it in terms of the timezone name, like "Central Time". "America/Chicago" bothers me because I don't know what cities are and aren't in your timezone database. The ones that have a tiny map that you have to click on are also pretty bad.
https://www.iana.org/time-zones "America/Chicago" is a standard timezone name.
Right, but very few people living in the continental US[0], when presented with a timezone dropdown, are going to expect to see anything but Eastern, Central, Mountain, or Pacific. If they do see a list that has city names, they'll be confused that their city isn't mentioned, or that they're expected to pick a city that's in their timezone but possibly geographically distant.
Personally, I (living in SF), use the "PST8PDT" named timezone; it just makes more sense to me than "America/Los Angeles", which is 400+ miles away from me (even though historically we've always had the same time as LA... as far as I know).
[0] Yes, there are a few places in the continental US that don't follow the "normal" 4 timezones and their DST schedules, so there are exceptions; specifically calling out those cities/locales is necessary, at least in those cases.