Я знаю, что это старый, но надеюсь, что это поможет кому-то в будущем.
Вот XML Я десериализации:
<timePeriod>1982-03-31T00:00:00+11:00</t
После десериализации XML Я в конечном итоге с 30 не 31:
Оказывается, 3-й партии, которые производят этот XML (который я использую) меняет TimeZone на +11 во время летнего времени и сохраняю его как +10, если не летнее время (DST).
Согласно Jon тарелочкам UTC не должен считать DST: https://stackoverflow.com/a/5495816/495455
отметить также документацию
Coding Best Practices Using DateTime in the .NET Framework:
XML-сериализатор всегда предполагает, что значения DateTime сериализуемый представляют местное время машины, так он применяет смещение локального часового пояса машины в качестве смещенной части закодированного времени XML. Когда мы десериализируем это на другой машине, исходное смещение вычитается из обрабатываемого значения и добавляется смещение часового пояса текущей машины.
Следующий код позволил мне получить дату отформатированный как 31, но это не будет работать 100% для не даты Daylioght Saving (приведенных в данном сырье):
TimeZoneInfo easternZone = TimeZoneInfo.FindSystemTimeZoneById("AUS Eastern Standard Time");
DateTime easternTimeNow = TimeZoneInfo.ConvertTimeFromUtc(dataPoint.timePeriod, easternZone);
System.Diagnostics.Debug.WriteLine(easternTimeNow.ToString());
Поэтому решение является исправить XML-канал, чтобы он не чередовал UTC с DST.
EDIT:почему данные облажался
Как выясняется, его не 3-го поставщика партии изменения UTC с летнего времени. XML-канал создается базой Java Swing, читающей SQL-дБ. Обычно я бы рекомендовал хранить стандартное представление XML (xsd: dateTime) - IS0 8601, но в этом случае использовать строку и копировать все после работы T. Отказ от ответственности, я все еще пытаюсь изменить фид, рекомендую вам НЕ делать это в PROD. Используйте на свой риск!!
Может ли кто-нибудь дать мне ссылку на точный ответ на этот вопрос? (Передача DateTime с .Net сервера на клиент JavaScript) – Siddhant