FWIW, I found the following table of Time Zones on a Postgres reference page
(no, I don't use Postgres). Hope it helps.
- Jeff
"Time Zone","Offset from UTC","Description"
"NZDT","+13:00","New Zealand Daylight Time"
"IDLE","+12:00","International Date Line, East"
"NZST","+12:00","New Zealand Std Time"
"NZT","+12:00","New Zealand Time"
"AESST","+11:00 ","Australia Eastern Summer Std Time"
"ACSST","+10:30 ","Central Australia Summer Std Time"
"CADT","+10:30 ","Central Australia Daylight Savings Time"
"SADT","+10:30","South Australian Daylight Time"
"AEST","+10:00 ","Australia Eastern Std Time"
"EAST","+10:00 ","East Australian Std Time"
"GST","+10:00","Guam Std Time, USSR Zone 9"
"LIGT","+10:00","Melbourne, Australia"
"ACST","+09:30 ","Central Australia Std Time"
"CAST","+09:30 ","Central Australia Std Time"
"SAT","+9:30","South Australian Std Time"
"AWSST","+9:00 ","Australia Western Summer Std Time"
"JST","+9:00","Japan Std Time,USSR Zone 8"
"KST","+9:00","Korea Standard Time"
"WDT","+9:00","West Australian Daylight Time"
"MT","+8:30","Moluccas Time"
"AWST","+8:00 ","Australia Western Std Time"
"CCT","+8:00 ","China Coastal Time"
"WADT","+8:00","West Australian Daylight Time"
"WST","+8:00","West Australian Std Time"
"JT","+7:30","Java Time"
"WAST","+7:00","West Australian Std Time"
"IT","+3:30","Iran Time"
"BT","+3:00 ","Baghdad Time"
"EETDST","+3:00 ","Eastern Europe Daylight Savings Time"
"CETDST","+2:00 ","Central European Daylight Savings Time"
"EET","+2:00 ","Eastern Europe, USSR Zone 1"
"FWT","+2:00","French Winter Time"
"IST","+2:00","Israel Std Time"
"MEST","+2:00","Middle Europe Summer Time"
"METDST","+2:00","Middle Europe Daylight Time"
"SST","+2:00","Swedish Summer Time"
"BST","+1:00 ","British Summer Time"
"CET","+1:00 ","Central European Time"
"DNT","+1:00 ","Dansk Normal Tid"
"DST","+1:00 ","Dansk Standard Time (?)"
"FST","+1:00 ","French Summer Time"
"MET","+1:00","Middle Europe Time"
"MEWT","+1:00","Middle Europe Winter Time"
"MEZ","+1:00","Middle Europe Zone"
"NOR","+1:00","Norway Standard Time"
"SET","+1:00","Seychelles Time"
"SWT","+1:00","Swedish Winter Time"
"WETDST","+1:00","Western Europe Daylight Savings Time"
"GMT","0:00","Greenwish Mean Time"
"WET","0:00","Western Europe"
"WAT","-1:00","West Africa Time"
"NDT","-2:30","Newfoundland Daylight Time"
"ADT","-03:00 ","Atlantic Daylight Time"
"NFT","-3:30","Newfoundland Standard Time"
"NST","-3:30","Newfoundland Standard Time"
"AST","-4:00 ","Atlantic Std Time (Canada)"
"EDT","-4:00 ","Eastern Daylight Time"
"ZP4","-4:00","GMT +4 hours"
"CDT","-5:00 ","Central Daylight Time"
"EST","-5:00 ","Eastern Standard Time"
"ZP5","-5:00","GMT +5 hours"
"CST","-6:00 ","Central Std Time"
"MDT","-6:00","Mountain Daylight Time"
"ZP6","-6:00","GMT +6 hours"
"MST","-7:00","Mountain Standard Time"
"PDT","-7:00","Pacific Daylight Time"
"PST","-8:00","Pacific Std Time"
"YDT","-8:00","Yukon Daylight Time"
"HDT","-9:00","Hawaii/Alaska Daylight Time"
"YST","-9:00","Yukon Standard Time"
"AHST","-10:00 ","Alaska-Hawaii Std Time"
"CAT","-10:00 ","Central Alaska Time"
"NT","-11:00","Nome Time"
"IDLW","-12:00","International Date Line, West"
On 2 Apr 2001, at 8:17, Marc Funaro wrote:
> Hi All,
>
> An update on our progress to handle Time Zone info properly:
>
> At this point, I've built my user signup form with a drop-down box showing
> TZ Offsets half hour increments, and a checkbox for observing DST -- all of
> which is stored "per user", of course. Detecting this information
> automatically, as Marc Gadsdon mentioned, is just too risky. I think it's
> likely that the user will know what time zone they are in, and whether or
> not they observe Daylight Saving Time. In this particular app, it's
> important that we collect proper TZ info, but not absolutely detrimental if
> we don't.
>
> ALL dates and times are stored in the database in UTC, and based on the
> country, I built a custom tag which converts the UTC back to the user's
> local time, with plug-in capability for handling DST, since many places
> handle DST differently (i.e., EU starts DST one week earlier than U.S.,
> Brazil Starts on first Sunday in October and ends on the last Sunday in
> February, etc...). Some places simply will not be supported for DST, i.e.
> Israel always has Daylight Saving time, but it is decided every year. We
> don't anticipate this will be a problem, however... and we may be able to
> figure this one out eventually too.
>
> Anyway, we now can feed the custom tag a UTC, TZOffset and a yes/no for
> whether the user observes DST, and it kicks back the local time and DST date
> range. Finally, we may customize the interface for advanced users, allowing
> them to enter their OWN DST date range, associated with their user record,
> that would override the custom tag, if necessary. This is a last resort,
> but provides complete flexibility when supporting time zones.
>
> The custom tag's DST calculations currently only support North America,
> because we're on a deadline. But hopefully I'll be building the other DST
> plug-ins for places like South America, Australasia, Asia, Israel, etc after
> things slow down.
>
> In answer to the fudge question (read WAY down below!), I don't like
> changing raw data, period. It's one thing to adjust raw data by a known and
> sensible amount for logical mathematical reasons, i.e. to change a number
> system from base zero to base one for the Javascript month calculation; it's
> quite another to change data by a random or arbitrary amount just to get
> something to work. Plus, it would still require additional code to make
> sure that the change didn't actually cause more of a problem than it would
> have, i.e. adding a second to the user's time actually making it behave in
> the way that caused us to change it in the first place. It's just not good
> programming to make arbitrary adjustments, and it can come back to bite you
> later.
>
> I'd rather know why CF's tag/function has that nasty bug!
>
> m
>
>
>
> -----Original Message-----
> From: Marc Gadsdon [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 02, 2001 4:53 AM
> To: Fusebox
> Subject: RE: [OT] Timezone madness
>
>
> Another thought - what about those users who have their PCs incorrectly
> configured - a great deal of consumer PCs in the UK have their time zone
> incorrectly set to US settings!! Most system builders just slap the default
> install on and leave everything to the hapless customer. Also system clocks
> can quickly become more than an hour out - I've seen it and when you ask,
> the user just says "well it's always wrong - I just use my watch".
>
> It seems to me that relying on the PC is not a good idea. However the
> alternative is relying on the user to select the correct time zone info from
> a select box!!!
>
> Users! ;)
>
> Marc
>
> -----Original Message-----
> From: John Quarto-vonTivadar [mailto:[EMAIL PROTECTED]]
> Sent: 30 March 2001 20:46
> To: Fusebox
> Subject: Re: [OT] Timezone madness
>
>
> Hi Marc,
>
> > This is all off-subject at this point; the code I have DOES work, except
> for
> > this one-second "needed offset" in order for the offset hour to appear
> > properly.
>
>
> I'm following the thread with a great deal of interest--the reason I haven't
> piped in is because I cannot quite understand why you object to that "fudge
> factor" ? Since the time zone differences are in hours, how is adding a
> fudge of a second to get the right results any different than, say, C =
> A/(B+fudge) for a division? It sounds to me like you're doing this
> calculation at most once per user session (?) and you also don't seem to
> object to doing the tiny math to account for JS's month numbers of [0...11]
> ?? :)
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
