Why You Should Use Timezone Offsets Not Timezone Names
1–10 of 51 posts
Re: Why You Should Use Timezone Offsets Not Timezone Names
#2While I agree with your points when storing timing of (happened in the past) events, but I disagree when storing display preferences for the user. As a user, I do not want to change my timezone settings just because my country went into Daylight Saving.
Re: Why You Should Use Timezone Offsets Not Timezone Names
#3While I agree with your points when storing timing of (happened in the past) events, but I disagree when storing display preferences for the user. As a user, I do not want to change my timezone settings just because my country went into Daylight Saving.
Came here to make the same point. Named timezones like America/Los Angeles are still important because they refer to both the timezone offset as well as the DST rules that govern that particular political zone.
That being said, the gist of the post (time normalization) is obviously good. Stored time should always be UTC and converted for display later.
Re: Why You Should Use Timezone Offsets Not Timezone Names
#4The 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 future political changes will result in the wrong local times for users.
Re: Why You Should Use Timezone Offsets Not Timezone Names
#5No mention of epoch time in the article? Just store using epoch and convert to local time zone when displaying. That's how *nix does it.
Re: Why You Should Use Timezone Offsets Not Timezone Names
#6The 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 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 every monday for the next four weeks", then yes, you need to store the abstract time zone name so that the calendar program can translate each instance of that schedule to the appropriate instant.
Re: Why You Should Use Timezone Offsets Not Timezone Names
#7The 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..
Re: Why You Should Use Timezone Offsets Not Timezone Names
#8No mention of epoch time in the article? Just store using epoch and convert to local time zone when displaying. That's how *nix does it. https://en.wikipedia.org/wiki/Unix_time
Unix time is awful, since converting it to UTC is a real pain, as it doesn't count leap seconds which are included in UTC (thus, some seconds in Unix time are longer than others, or all of them are longer than standard SI seconds and the exact length fluctuates based on the introduction of leap seconds, or the like).
Re: Why You Should Use Timezone Offsets Not Timezone Names
#9No mention of epoch time in the article? Just store using epoch and convert to local time zone when displaying. That's how *nix does it. https://en.wikipedia.org/wiki/Unix_time
Unix time is awful, since converting it to UTC is a real pain, as it doesn't count leap seconds which are included in UTC (thus, some seconds in Unix time are longer than others, or all of them are longer than standard SI seconds and the exact length fluctuates based on the introduction of leap seconds, or the like).
leap seconds, or the like
Converting from epoch to the local timezone is supported in pretty much every language. I'm not sure why you think it's such a pain.
[1] https://dev.mysql.com/doc/refman/5.0/en/time-zone-leap-secon...
[2] http://googleblog.blogspot.com/2011/09/time-technology-and-l...
Re: Why You Should Use Timezone Offsets Not Timezone Names
#10I'd hate to be this guy's customer...