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
