I have a web application in ASP.NET that will be used globally. Data
is collected on mobile devices running Windows Mobile and sent to the
web server where it is stored and can be viewed. Data is timestamped
when it is sent from a PDA device to the server. I am writing software
for both the web app and the PDA. The web server is located at one
location while the PDA devices are located around the world.

The question is, how do I handle time when dealing in this situation?
I have to decide whether the timestamp on data sent from the PDA
should be either in local time or in UTC format. This is a lot tricker
than one might think. If I choose to use local time on the PDA and if
the person that is uploading their data wants to view the data on web,
they would see the correct time, provided I simply display the time as
it was sent without modifying it in any way. But if someone else in
another timezone is viewing that same data, the time would not
correspond to their timezone. That may or may not be a desired effect.
Some people perhaps would like to see all times in their local times.
To do that, times would have to be saved in UTC format and each
person's timezone offset would have to be stored on the server and
used when displaying data. But there is one problem with this
solution: daylight savings time.

There doesn't appear to be anything in the .NET Framework that can
handle daylight savings based on any given location. There is a
DaylightTime class and Timezone class but neither of these allow you
to specify a location. You can specify offsets for timezones but not a
location. The problem: you can effectively have two or more locations
with the same UTC offset but with different dates when daylight
savings time comes into effect.

The OS does handle daylight savings time correctly because when you go
to set the clock on your PC, you must pick a timezone and there are
multiple timezones using the same offset. But because the offset is
coupled with a location, it knows when the daylight savings time comes
into effect for that region.

So I'm not sure what approach to take. Allowing people to view data
from different timezones in their own local time is not a requirement
but probably would be nice. But to do that, the daylight savings time
would really need to be taken into account.

Any suggestions?

Thanks
Johann

On May 28, 9:01 am, Polaris431 <polaris...@gmail.com> wrote:
> Data is timestamped
> when it is sent from a PDA device to the server.

Johann,

what kind of date it is? If it's a date/time when data were stored on
the server, then you can use a server time.

Cheers

On May 28, 9:39 am, Alexey Smirnov <alexey.smir...@gmail.com> wrote:
> On May 28, 9:01 am, Polaris431 <polaris...@gmail.com> wrote:
>
> > Data is timestamped
> > when it is sent from a PDA device to the server.
>
> Johann,
>
> what kind of date it is? If it's a date/time when data were stored on
> the server, then you can use a server time.
>
> Cheers

Dates include both the date and time. I'm not sure what you are
getting at. "Use a server time" doesn't take daylights savings time
into account for the location where the viewer is located when they
view the date and time on the web.

On May 28, 10:09 am, Polaris431 <polaris...@gmail.com> wrote:
> Dates include both the date and time. I'm not sure what you are
> getting at. "Use a server time" doesn't take daylights savings time
> into account for the location where the viewer is located when they
> view the date and time on the web.

I think, you will need it only for the specific user and the current
time zone of the user. When you stored a date in UTC on the server you
can use later the DateTime.IsDaylightSavingTime() method to find
whether it is within the DST range for the user's time zone. I think,
this approach ensures that the global view of date/time will be
correct.

If you will send a local user date to the server, you can have a
problems with DST. For example, in fall, clocks turn backward one
hour. It means that day would have two times values between X:00 and (X
+1):00 (and a 25-hour day). The server will not recognize if received
date/time occured prior to the switch, or after that. But this
approach ensures that the local view of date/time will be correct.

As I see it, it's a no-brainer.

Use UTC time whenever you store a DateTime value. It's consistent across
time zones, and linear regardless of daylight savings time. This way you
will never have any problem with what a stored DateTime value
represents, and there are no gaps or overlaps of times at the change of
daylight savings time.

When someone inputs a value, convert it from their local time zone to
UTC. When you output a value, convert it from UTC to their local time
zone. It's a little more work than just storing their local time, but on
the other hand it's all the conversion you ever have to do with the dates.

Allowing people to view data from other time zones is no problem either,
as the values are stored independently of timezones. When you convert it
to their local time zone it will always show what the time was in their
time zone at that moment.

--
Göran Andersson
_____
http://www.guffa.com