Distributed model date time strategy

[markric]

I recently posted this message to
microsoft.public.dotnet.framework.aspnet.webservic es, but received no
response, so I'm trying here in this group. I could really use some
feedback.

I'm working on a commercial application that will have data, web
service, and client application tiers. I have no control over where any
of these systems might be deployed, and it's fairly likely that users
running the client application will be in different time zones than the
web service and database server.

What I'd like to do is always store date/time values in the database in
UTC (GMT) format, and then convert them to local date/time values on
the client side. This should minimize the need to be concerned about
time zones in general.

I believe what's required here is that DateTime objects in .NET code
use the ToUniversalTime() function prior to be stored in the database
(a SQL Server in this case). Then I would always call ToLocalTime()
when I display any of these values in the client application. The
client will *always* go through an ASP.NET (ASMX) web service tier to
read/write any data (including date/time values).

Does this seem logical? Any gotchas that I'm overlooking? Just as an
aside, I'm using .NET 2.0 through all layers.

I'd very much appreciate any input, and thanks.

- Mark

[Michael Nemtsev]

It's okay and logical. What does confuse you?

I recently posted this message to
microsoft.public.dotnet.framework.aspnet.webservic es, but received no
response, so I'm trying here in this group. I could really use some
feedback.

I'm working on a commercial application that will have data, web
service, and client application tiers. I have no control over where
any of these systems might be deployed, and it's fairly likely that
users running the client application will be in different time zones
than the web service and database server.

What I'd like to do is always store date/time values in the database
in UTC (GMT) format, and then convert them to local date/time values
on the client side. This should minimize the need to be concerned
about time zones in general.

I believe what's required here is that DateTime objects in .NET code
use the ToUniversalTime() function prior to be stored in the database
(a SQL Server in this case). Then I would always call ToLocalTime()
when I display any of these values in the client application. The
client will *always* go through an ASP.NET (ASMX) web service tier to
read/write any data (including date/time values).

Does this seem logical? Any gotchas that I'm overlooking? Just as an
aside, I'm using .NET 2.0 through all layers.

I'd very much appreciate any input, and thanks.

- Mark

---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

[Josh Twist]

Hi Mark,

I just replied to your other post - sorry for the delay. I posted my
findings here:
http://www.thejoyofcode.com/DateTime..._Services.aspx

Josh
http://www.thejoyofcode.com/