Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why You Should Use Timezone Offsets Not Timezone Names

tantek.com

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Why You Should Use Timezone Offsets Not Timezone Names

#41

Post by nvivo »

function_seven wrote: post #25
Zarel wrote: post #15

Earlier 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.

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…

The reason for Country/City is because the timezone name is a global reference. It may be written in english, but everybody uses. Things like "pacific", "central" and "standard" mean very different things in other places.

Re: Why You Should Use Timezone Offsets Not Timezone Names

#43

Post by nvivo »

saurik wrote: post #18
Zarel wrote: post #15

Earlier 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.

No, if you say CST you specifically mean China Standard Time. Most people in the world would agree.

Re: Why You Should Use Timezone Offsets Not Timezone Names

#44

Post by asdfaoeu »

kelnos wrote: post #32
saurik wrote: post #18

Earlier quoted context omitted.

CST is not the same thing as America/Chicago. If you say CST you specifically do not mean daylight savings time, which is CDT.

Sure, but the parent didn't say "CST". For a user-facing interface, presenting random city names is terrible. "Central Time" is a known entity among users, and they implicitly assume that it will take care of the difference between CST and CDT (and in fact, the named timezone CST6CDT does exactly that). Hell, if Chicago one day decided to be like a few of the "weird" US cities and not follow the standard DST schedule…

A fair number of timezones don't have a name for the full timezone that implies those specific daylight savings rules. Maybe it'd work for there and they should call CST6CDT, "Central Time".

Re: Why You Should Use Timezone Offsets Not Timezone Names

#45

Post by notfoss »

wizardry90210 wrote: post #4

The 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…

Yeah, this comment is so spot on, considering that North Korea just announced a new timezone for themselves.

Re: Why You Should Use Timezone Offsets Not Timezone Names

#46

Post by tankenmate »

nvivo wrote: post #41
function_seven wrote: post #25

Earlier quoted context omitted.

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…

The reason for Country/City is because the timezone name is a global reference. It may be written in english, but everybody uses. Things like "pacific", "central" and "standard" mean very different things in other places.

Indeed, for many years the Eastern time zone in Australia was shortened to EST (Eastern Standard Time); just like the US Eastern time. With the wider advent of the Internet Australia renamed EST to AEST (Australian Eastern Standard Time).

Re: Why You Should Use Timezone Offsets Not Timezone Names

#47

Post by graniter »

It depends on how the data is going to be used. If you want absolute time, save it as UTC or local with an offset. But if a user is going to think of "7pm my time" then you probably are going to need to save "7pm" and the user's timezone separately so that 7pm always shows as 7pm even after Daylight Savings changes or other timezone rule changes. Save the date and time relative to the context of a timezone (not offset).

There are a lot more timezones than there are offsets, and several timezones may have the same offset at a given point in time, but that may not be true every day of the year because they have different rules.

So the robust solution is to make all your datetimes "timezone" aware, not "offset" aware. And yes that means using the Olsen Data and yes that means more complications. But it's the only way to have accuracy for human-oriented datetimes.

Re: Why You Should Use Timezone Offsets Not Timezone Names

#48

Post by Zarel »

nvivo wrote: post #40
Zarel wrote: post #15

Earlier 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.

Central to where? The other 96% of the world that are not in the US don't agree with your very specific notion of "central".

https://en.wikipedia.org/wiki/Central_Time_Zone

The one in the Americas is the only one called "Central Time". It may not be the most politically correct name, but it happens to be the only name for it I know of, and it's the only timezone with that exact name worldwide.

Re: Why You Should Use Timezone Offsets Not Timezone Names

#49

Post by Zarel »

gohrt wrote: post #23
Zarel wrote: post #15

Earlier 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.

I just googled "Omaha, NE timezone", and "America/Chicago" was not anywhere in the results.

http://google.com/search?q=Omaha,+NE+timezone

It may be a standard timezone name, but it's not a very user-friendly one.

Re: Why You Should Use Timezone Offsets Not Timezone Names

#50

Post by kelnos »

justincormack wrote: post #38
kelnos wrote: post #32

Earlier quoted context omitted.

Sure, but the parent didn't say "CST". For a user-facing interface, presenting random city names is terrible. "Central Time" is a known entity among users, and they implicitly assume that it will take care of the difference between CST and CDT (and in fact, the named timezone CST6CDT does exactly that). Hell, if Chicago one day decided to be like a few of the "weird" US cities and not follow the standard DST schedule…

Not necessarily. I am giving a talk in San Marcos, TX at 11am next week, but I have no idea what time zone it is in as I am not American.

I'm not talking about people in your situation; I guess that wasn't clear. I'm talking about someone setting the time zone on their personal hardware. They know where they live and what their time zone is.

Besides, for your case there are easier methods, like Googling "current time in San Marcos, TX" (which Google will actually tell you the time and time zone without you needing to click on a results page; if you feel the need to, the first result has all the info you need as well). Hell, the "world clock" app on my phone tells me what I need to know when I enter in that city.

Post reply on HN