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
Hi Josh,
Thanks very much for the informative reply. I performed similar testing
here, and arrived at a similar conclusion, but it was very helpful to
have another perspective.
I think that for my particular scenario, I'm creating a problem that
doesn't exist. I believe my confusion stemmed from the idea that SQL
Server doesn't store any time zone information, leading me to believe
that the stored value ultimately needed to be standardized in some
fashion and then converted at various endpoints.
However, if the web service layer always converts a stored datetime to
it's local time zone prior to transmitting it, and then the client
applications convert to their time zone again upon dipslay, then I
don't think it really matters. The .NET framework seems to handle the
details.
Thanks again for the input!
- Mark
Don't see what you're looking for? Try a search.
| 