3 ms·
I work on a calendar application and I can attest to all kinds of issues dealing with time, dates, and time zones. It's very difficult to get right and most of
by Osiris 14y ago
I work on a calendar application and I can attest to all kinds of issues dealing with time, dates, and time zones. It's very difficult to get right and most of the time we just hope that for our purposes it's close enough.
A big issue is dealing with timezone conversions especially because different applications represent time zones with different english language versions of the names, like "US Mountain Standard Time" (used by Outlook) is the same as "US/Arizona" (used by PHP among others).
- BrandonM 14y ago> "US Mountain Standard Time" (used by Outlook) is the same as "US/Arizona" (used by PHP among others). It's not quite that simple. During Daylight Saving Time, Arizona stays on US Mountain Standard Time; i.e., it's the same as Pacific Daylight Time and one hour behind Mountain Daylight Time. During the rest of the year, Arizona is on the same time as the rest of Mountain Standard Time, or one hour ahead of Pacific Time.
- adavies42 14y agothe "country/(city/region)" notation is from zoneinfo, the standard unix timezone system. "X standard time" (and "X daylight time") are the common names most people in america use when referring to timezones. zoneinfo's form has the benefit of having a nice, unambiguous way to refer to the various daylight-saving time exceptions (arizona, indiana, hawaii, etc.). recently i've seen huge timezone lists that basically throw in the kitchen sink--they'll have the entire zoneinfo set, the common american names, miscellaneous other common regional names (euro, australia, etc.) and raw whole-hour offsets as well. makes for a long drop-down to navigate....