local time for remote users

[MarcG]

I have an aspnet/sql2005 app that supports a set of local users in a
manufacturing environment. I (thoughtlessly) built it using SQL's GetDate()
and Framework's DateTime.Now function/property.

Everything was fine until the client decided to use the app for its plant in
the far east. The good news is that the far east system will not share a
database with the local one. The bad news is that the far east app will run
on the same IIS and SQL server as the local app (i.e., here in north america).

So what I now have is two instances of the app and database running in
separate app pools.

Obviously I haven't worked with internationalization apps before and said
"Oh, yeah, hadn't thought of that..." when the client called and asked why
the far east userswere saying that timestamps were off by 13 hours. I'm going
to have to fix this, but fortunately they haven't asked for output in
Cantonese.

So, what is the "right" way to deal with the general problem an app faces
when wanting to present time information to remote users according to their
local time zone?

If it helps, I think that I should have timestamps in the database reflect
the user's local time since in THIS case, the local and far east plants
represent different business units and the data will not be combined for
reporting purposes (i.e., I don't have the general problem of users from
different time zones sharing data and it is the time zone of the business
unit I'm trying to deal with).

It would be great, but I think impossible, to have a time zone associted
with the app pool and the database instance.

Thx
Marc

 

[Guest]

I have an aspnet/sql2005 app that supports a set of local users in a
manufacturing environment. I (thoughtlessly) built it using SQL's GetDate()
and Framework's DateTime.Now function/property.

Everything was fine until the client decided to use the app for its plant in
the far east. The good news is that the far east system will not share a
database with the local one. The bad news is that the far east app will run
on the same IIS and SQL server as the local app (i.e., here in north america).

So what I now have is two instances of the app and database running in
separate app pools.

Obviously I haven't worked with internationalization apps before and said
"Oh, yeah, hadn't thought of that..." when the client called and asked why
the far east userswere saying that timestamps were off by 13 hours. I'm going
to have to fix this, but fortunately they haven't asked for output in
Cantonese.

So, what is the "right" way to deal with the general problem an app faces
when wanting to present time information to remote users according to their
local time zone?

If it helps, I think that I should have timestamps in the database reflect
the user's local time since in THIS case, the local and far east plants
represent different business units and the data will not be combined for
reporting purposes (i.e., I don't have the general problem of users from
different time zones sharing data and it is the time zone of the business
unit I'm trying to deal with).

It would be great, but I think impossible, to have a time zone associted
with the app pool and the database instance.

Thx
Marc

In your case I think I would just add an offset value in the
web.config file in each application and use that value in the
application to display right time according to the offset.

<appSettings>
<add key="offset" value="13" />
</appSettings>

int offset =
Convert.ToInt32(ConfigurationSettings.AppSettings["offset"]);
DateTime dt = ...from the db...
DateTime desiredTime = dt.AddHours(offset);

If you would have more than one location then you should consider
having the offset settings in the user profile (or based on a client
IP address, etc.)

 

[Steven Cheng]

Thanks for Alexey's input.

Hi Marc,

ASP.NET globalization can help you do some UI rendering or time/currency
formatting depend on the UICulture and Culture info you set for the ASP.NET
worker thread.

#How to: Set the Culture and UI Culture for ASP.NET Web Page Globalization
http://msdn2.microsoft.com/en-us/library/bz9tc508.aspx

However, for Datetime of remote client user, ASP.NET/http request won't
send such information(only some user-language info will be sent).
Therefore, the reasonable approach would be:

1. You may let the user choose their timezone(stored as a profile item of
each user) and on the page where you need to display datetime, you may
manually calculate the correct time via the timezone offset in current
user's profile.

2. Stored a static timezone offset in web.config file and retrieve it at
runtime when you want to display time info.

Also, is it possible that you use UTC time for all the users?

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.



--------------------

From: Anon User <>
Newsgroups: microsoft.public.dotnet.framework.aspnet
Subject: Re: local time for remote users
Date: Tue, 19 Feb 2008 10:48:19 -0800 (PST)

why> the far east userswere saying that timestamps were off by 13 hours.
I'm goingreflect> the user's local time since in THIS case, the local and far east
plants

represent different business units and the data will not be combined for
reporting purposes (i.e., I don't have the general problem of users from
different time zones sharing data and it is the time zone of the business
unit I'm trying to deal with).

It would be great, but I think impossible, to have a time zone associted
with the app pool and the database instance.

Thx
Marc

In your case I think I would just add an offset value in the
web.config file in each application and use that value in the
application to display right time according to the offset.
<appSettings>
<add key="offset" value="13" />
</appSettings>
int offset =
Convert.ToInt32(ConfigurationSettings.AppSettings["offset"]);
DateTime dt = ...from the db...
DateTime desiredTime = dt.AddHours(offset);
If you would have more than one location then you should consider
having the offset settings in the user profile (or based on a client
IP address, etc.)

 

[Andrew Morton]

Don't forget about summer time adjustment, too.

Andrew

 

[MarcG]

Thanks all,

This is going to be as ugly as I expected. I note Andrew's comment about
sumer hours, which I had thought of and was hoping to be able to avoid by
relying on MS. This doesn't seem like an unusual problem (sigh).

In order to avoid having to work out who is on what time zone and how it
should be adjusted for local conditions, I think I'll take advantage of the
fact that I control the code.

When the user posts from my splash screen, I'll add a parameter to the
request that contains the local machine time. I'll look at the difference
between the post time and my server's machine time. Allowing for transmission
time, it should be pretty close to an integer number of hours (actually half
hours if you want to worry about places like Newfoundland). Once I've rounded
appropriately, I should have something like (in my case) 13 hours, or 12 or
14 depending on who is on DST. This establishes the offset on a per user
basis. Since the timestamp I'm trying to generate and display reflects the
time of the user's action in their time reference, I believe that this will
solve the problem. In fact, I could, but won't, combine the data from both
databases into one.

One possible hitch is that I'm relying on the user's local machine time as
being correct. Since this is a corporate environment and the machines are
centrally managed, and there are lots of reasons for time to be correct, I
think I'm safe.

It would be nice if the HTTP Request headers provided the time of the
request (the Response header provides the time of the response), but since it
doesn't I'll get the same effect by adding the request time as a parameter.

I think that that does it. Please comment if I've missed something.

Thx
Marc

 

[Steven Cheng]

Thanks for your reply,

Yes, I agree that the most reliable way is to collect the time info from
client via user input since built-in http or ASP.NET data doesn't collect
this by default.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Thanks all,

This is going to be as ugly as I expected. I note Andrew's comment about
sumer hours, which I had thought of and was hoping to be able to avoid by
relying on MS. This doesn't seem like an unusual problem (sigh).

In order to avoid having to work out who is on what time zone and how it
should be adjusted for local conditions, I think I'll take advantage of the
fact that I control the code.

When the user posts from my splash screen, I'll add a parameter to the
request that contains the local machine time. I'll look at the difference
between the post time and my server's machine time. Allowing for transmission
time, it should be pretty close to an integer number of hours (actually half
hours if you want to worry about places like Newfoundland). Once I've rounded
appropriately, I should have something like (in my case) 13 hours, or 12 or
14 depending on who is on DST. This establishes the offset on a per user
basis. Since the timestamp I'm trying to generate and display reflects the
time of the user's action in their time reference, I believe that this will
solve the problem. In fact, I could, but won't, combine the data from both
databases into one.

One possible hitch is that I'm relying on the user's local machine time as
being correct. Since this is a corporate environment and the machines are
centrally managed, and there are lots of reasons for time to be correct, I
think I'm safe.

It would be nice if the HTTP Request headers provided the time of the
request (the Response header provides the time of the response), but since it
doesn't I'll get the same effect by adding the request time as a parameter..

I think that that does it. Please comment if I've missed something.

Thx
Marc

I think you can also try to use a client-side script to get the time/
time zone from the client. Then you can compare it with a server value
and/or redirect to another page using the time as a query string
parameter value. After that you can decide on the server side what
time should be used to display

For example, add this to your initial page

<script language="javascript">
var curDate = new Date();
var curHour = curDate.getHours();
...
// now you can redirect
window.location.href="default.aspx?time="+curHour;
...
// or you can compare with the server time
var serverHour = <%=DateTime.Now.Hour%>
if (curHour > serverHour){
window.location.href="default.aspx?time="+curHour;
...
// or you can get offset in minutes
var curOffset = ourDate.getTimezoneOffset();
...
</script>

Hope this helps