Adjusting to user's local time

Andy:

Fair enough.

Can we assume that a user in one particular time zone will ALWAYS be in that
particular time zone? If so, you may need to capture the time difference as
part of the subscription. I believe Windows time zone tables include an
integer field that would indicate this.

Sorry that I cannot take you any further. I don't have experience or
knowledge of how to tap into the OS to get something like that.

If the user signs up for the subscription while in China, and expects the
notification to be formatted correctly for him while he just happens to be in
Athens, then you REALLY have your work cut out for you.

Things were SO much simpler when the world was FLAT



--
Todd C

[If this response was helpful, please indicate by clicking the appropriate
answer at the bottom]


"Andy" wrote:

> On Jul 19, 8:18 am, Todd C <To... DeleteThis @discussions.microsoft.com> wrote:
> > Why not do this:
> >
> > [Expiration in Local Time] = DateAdd(hour, DateDiff(hour, GETUTCDATE(),
> > GETDATE()), [Expiration in UTC Time])
> >
> > One caution: This only applies to records where the [Expiration Date] is in
> > the same Daylight Savings timeframe as the current date. In other words, this
> > is accurate if you are looking at an [Expiration Date] coming up in a week.
> > But if you are looking at an [Expiration Date] that will be in, say, November
> > or December (after the U.S. has gone off Daylight Savings Time) then you will
> > be off by one hour.
> >
> > The choice is yours: If that one hour difference is acceptable for 6 months
> > out of the year, then it will work. If not, you will need to figure out
> > something else.
>
> Well the problem is that users may be in China, France, or Germany,
> and this only accounts for users in the same timezone in which the
> server is located.
>
>
 >> Stay informed about: Adjusting to user's local time