Time Function returns Wrong Time

Discussion in 'ASP General' started by RICHARD BROMBERG, Oct 15, 2005.

  1. I am writing an ASP program that includes a Form.

    When the Form is submitted I use the Date() and Time() functions to put the
    date and time into the Body part of the e-mail.
    The time reported is three hours earlier than the time at which the Form is
    actually submitted.

    I understand these functions are evaluated on the server so the server must
    be in a time zone three hours earlier than where I am .

    Is there any way I can get the local time at the location where the user is
    actually located. ??

    RICHARD BROMBERG, Oct 15, 2005
    1. Advertisements


    Evertjan. Guest

    RICHARD BROMBERG wrote on 15 okt 2005 in
    The ASP of the form submitting page is unimportant for your Q.

    The page the form is submitted to should be an .asp page.
    Are you sure this is serverside ASP?

    ASP vbscript now() contains both date and time.
    All ASP code is executed on the server.
    However Date() and Time() could also be clientside VBS on a IE browser.
    If you mean by "ASP program" "ASP vbscript":

    myDateTime = DateAdd("h", 3, Now)
    Evertjan., Oct 15, 2005
    1. Advertisements

  3. 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.


    (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...)

    Well now that's not entirely true, is it? Will he not construct that form,
    as well as any event script, in ASP?

    Painfully obvious, content == 0.

    Yes he's sure, you dimwit, the functions Date() and Time() are both
    supported by VBS -- condescending and stupid is a really poor combination.

    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.

    "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.

    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...

    Mark J. McGinty, Oct 16, 2005

    Bullschmidt Guest

    Bullschmidt, Oct 17, 2005
  5. Oops, this:
    should of course read:

    .... post both the timezone offset and the *local* time-of-day from the
    client to yourself, use them to calc UTC, convert your server time to UTC...

    Sorry about that,
    Mark J. McGinty, Oct 17, 2005
  6. Many thanks to almost one and all.

    The response from Evertjan in the Netherlands was useless, Just a small
    pothole in the internet superhighway.
    RICHARD BROMBERG, Oct 17, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.