[Mono-list] A big (MS created) flaw in DateTime that surfaces in Web Services
Mon, 30 Jun 2003 15:27:35 +0200
> Here is an example you can possibly test for yourself.
> I have two DateTimes one containing 1998/10/16T00:00:00000 (a friday) and
> the other 1998/10/19T00:00:00000 (a monday) both without time zone
> information and both extracted from a database.
> The server is in a time zone so that it decides to encode them as:
> 1998/10/16T00:00:00000-03:00 (normal period of the year) and
> 1998/10/19T00:00:00000-02:00 (because it crossed into a daylight savings
> The problem is that the client is theoretically in the same time zone but
> ends parsing it back as follow:
> 1998/10/18T23:00:00000 (became sunday 11pm). THAT IS THE PROBLEM
> Even if I'm wrong about both machines staying in the same time zone, I
> want the information to change because in truth the server may be housed
> São Paulo, but this data has many sources around the globe (Tokyo and New
> York, for example), and Dates and Times are already universalized in the
> database and are to be shown as stored not adjusted.
Ok, I never had to deal with this issue, but I see your point.
The first problem is that the only relevant information for you is the date,
not the time. In this case you should serialize the DateTime value as a
"date", not "dateTime" (which is the default). You can use for example this
This works in MS.NET, but not yet in Mono (I put it in my TODO list).
The second problem is another one. Regarding Web Services, I would say that
in general the inclusion of the UTC offset in the datetime is not bad. WS
are commonly used to communicate decoupled systems that don't know much
about one each other, so it is good to include this info to make sure that
times are not misunderstood. However, in other scenarios, like the one you
described, this *feature* turns out to be a problem.
I think that there should be freedom of choice about whether including UTC
info or not. AFAIK, currently there is no such choice.
IMHO, there is no need to extend DateTime to include UTC info, because you
can use always the same reference timezone (that could be GMT+0), and you
can make conversions from one timezone to another one if you need to (if the
previous issue was solved, of course). (BTW, is there any database that can
store dates with UTC info?).
If you are designing an application that will deal with dates coming from
several timezones, that dates should be stored using GMT+0, and you can
convert them to local time just for displaying the dates on the user
interface. When exchanging dates between remote systems (either through WS
or remoting), dates in GMT+0 should also be used. But well, it seems that
this is just what you are doing.