A reader asks:
We have an issue with the DateTime data type using serialization across timezones. All works well where we are interested in both the date and time. However, when the Date portion is of interest only, for example Birthday, (not many people know the exact time nor do they generally care), so the time portion will be 00:00:00 as initialised. As this is serialized and sent over a timezone this date could be changed to be the previous day, with a time of 23:00:00. If this user then logged into the system in the other time zone they would now see their birthday as being a day earlier and they would complain it was incorrect; rightly so. In our opinion this is not correct, the date should not change when time is irrelevant. As a suggestion it would be good if there was a property on the DateTime to mark it is Date only. This would result in an exception if the time portion was maintained, and the serialization would not change the value over time zones.
I gathered some comments from the product team on this that I thought were thoughtful and generally interesting so I am posting them here.
This is an issue I have seen a few times before.
For V1.0 and V1.1, There is a work-around for XML Serialization. You can indicate in the schema that the DateTime is a Date only. If you start from schema, you should use xsd:date primitive type, to change the object model you can use custom attribute on the member:
public DateTime date;
public DateTime date;
Notice that this will not work for DataSet or SOAP Serializer.
Another work around is to call ToLocalTime() on the DateTime before serializing and ToUniversalTime() after serializing. This is sort of cheating because it is not really a UTC date, but it should make the time zone adjustment go away.
In a future release we do have planned a solution that is similar but not identical to what you have requested. You can mark a DateTime instance as Local, UTC or Unspecified, and Unspecified means that it should not be serialized with a time zone. Unfortunately it won’t magically take effect because it would break compatibility. But there will be ways to opt-in to this behavior for DataSet, XML Serialization and XML Convert.