To the OP, you'll have to forgive Captain A-hole's purposeful lack of
anything usable in his reply. It's a little game of his, he likes to be as
diminutive as possible without compromising the overtly disingenuous nature
of the non-information he 'shares.'
As for a solution, the most straight-forward way is to create a [JavaScript]
Date object on the client, call it's getTimezoneOffset() method, and post
the result to the server in a hidden input, optionally keeping it as part
of the user's profile data.
Sadly it's sometimes the case that the user has the time-of-day set for
his/her geographic area, but has the wrong timezone configured. Further, as
a matter of logistics more than anything, you can expect the time-of-day
(UTC) according to any given machine, to vary slightly from your server.
So if accuracy is of extreme importance, you should post both the timezone
offset and the time-of-day (UTC) from the client to yourself, convert your
server time to UTC, and see if they match, +-15 minutes or so. If not,
inform the user that there is a configuration issue.
Given that you can trust the timezone offset, acquire it from the client via
script, and use it to calculate the transaction time-of-day stamp from
server time. Better yet, always store server-based time-of-day stamp as
UTC, and adjust it to local time when you render the page.
Resist the temptation to simply acquire and store the local time-of-day from
the client. People have been known to forge time-of-day stamps by adjusting
their system time. Server time is more reliable; storing it as UTC gives
you an always-known frame of reference, and avoids inaccuracy caused by
multiple conversions.
So to correct myself, the most straight-forward way is to use your server's
time, stored as UTC, and render it as local time when you render the page,
based on timezone offset.
-Mark
(btw, "Evertjan", I'll top-post any time I damn well please, if you have an
issue, keep it to yourself. See other comments injected into post below...)
Evertjan. said:
RICHARD BROMBERG wrote on 15 okt 2005 in
microsoft.public.inetserver.asp.general:
The ASP of the form submitting page is unimportant for your Q.
Well now that's not entirely true, is it? Will he not construct that form,
as well as any event script, in ASP?
The page the form is submitted to should be an .asp page.
Painfully obvious, content == 0.
Are you sure this is serverside ASP?
Yes he's sure, you dimwit, the functions Date() and Time() are both
supported by VBS -- condescending and stupid is a really poor combination.
ASP vbscript now() contains both date and time.
All ASP code is executed on the server.
No kidding? Wow, I wonder if the OP was making reference to this with his
statement, "I understand these functions are evaluated on the server". Bah,
no, couldn't possibly, thank the heavens we have "Evertjan" to set us
straight on these complex topics.
However Date() and Time() could also be clientside VBS on a IE browser.
If you mean by "ASP program" "ASP vbscript":
"Program" is a substantially correct term -- was there a point you were
trying to make? A relevant point? Something that might enhance the
discussion and leave the OP better-informed? If so, I can't imagine what it
would be, other than perhaps your asserting your god-given right to waste a
few dozen bytes of bandwidth... again.
myDateTime = DateAdd("h", 3, Now)
Hey now! There's an inspired solution, hard-code a 3 hour offset on the
server side -- are you available to, like, write "ASP vbscript" um...
programs or something? What's your rate? That's the kind of dynamic you
just can't find everywhere, ya know? How lucky we are that you so
generously shared your methodology with us.
Oh btw, what happens if people from more than just one timezone use the
site? Hmm, your solution doesn't seem to consider that in the slightest...
Oh gosh, that makes it sort of... useless, doesn't it? I guess I'm left
shocked and amazed...
