вот есть интересные замечания по этому поводу -

DateTime, Serialization and TimeZones
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:

[XmlElementAttribute(DataType="date")]
public DateTime date;

or

[XmlAttributeAttribute(DataType="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.

http://blogs.msdn.com/brada/archive/2004/04/13/112784.aspx

Вобщем основной смысл, мне кажется в этом -

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.

Ещё один вариант - вызывать ToLocalTime() для DateTime перед сериализацией и ToUniversalTime() после сериализации. Это в некотором роде трюк, поскольку это не UTC дата, но поможет вам убрать корректировку временной зоны.

Т.е. попробовать

DateTime DT1;
DateTime DT=new DateTime();
DT = DateTime.Now;
DT1 = DT.ToLocalTime();
label1.Text=DT1.ToUniversalTime().ToString();

мда, что-то в этом супе не то (((

http://search.microsoft.com/search/results.aspx?qu=timezone+daylight&View=msdn&st=b&c=4&s=2

Вот есть ссылка, где daylight - летнее время, т.е. надо кажется рыть в сторону класса TimeZone, больше пока помочь ничем не могу (((

Ага, большинство источников пишут, что автоматом нельзя получить такой перевод - его надо делать вручную, используя, видимо, эти методы:

DateTime.ToUniversalTime
DateTime.ToFileTime
TimeZone.GetUtcOffset
TimeZone.IsDaylightSavingTime
TimeZone.ToUniversalTime

***
сплошные догадки, сам никогда с временем особо не работал.

Да, похоже на то.
Если понадобится - тоже буду знать )