> Yeah, but if it's centralized, why do you need to keep
> track of time zones? If someone wants to go to the doc
> at 1:00pm, then just sign them up for 1:00pm.
My guess is that it is not centralized-- like an ASP architecture, where
doctors sign up for a web service that allows their patients to sign up for
appointments online, but the server hosting the service does so for a
variety of locations (one in Alaska, one in Florida, say).
If that is the case, and I am making a big assumption there, then there are
a couple solutions:
1) if the doctor is in one location, let her set up the time zone she wants
her patients to conform to, and then set the time zone accordingly in the
app (session/client var)
2) If it isn't that simple, use the zip code or area code the user enters to
figure it out, or better yet, ask them to enter their time zone.
3) Risky, because this depends on the users knowing how to set the clock on
their computer, is to send the server time to the browser via JavaScript,
get the client's machine's time via JavaScript, and reverse engineer the
time zone based on the the difference.
Essential) no matter what solution you use, just label the dang appointment
times, so there can be no confusion. If the server is in FL, say the time
is 8:00 Eastern; CO 6:00 Mountain...
You get the point...
David Huyck
[EMAIL PROTECTED]
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
