2

Germany introduced a summer time shift on 6. April 1980.

Therefore I would expect the time shift on 1979 to GMT+1 and on 1980 to GMT+2

In Javascript this is correct:

new Date("1979-06-18T00:00:00.000")
new Date("1980-06-18T00:00:00.000")

JS Console Output

How ever, when trying the same thing with C#, I have always 2 hours time shift.

var foo1 = new DateTime(1980, 6, 18, 0, 0, 0, DateTimeKind.Local).ToString("O");
var foo2 = new DateTime(1979, 6, 18, 0, 0, 0, DateTimeKind.Local).ToString("O");

C# Output

I think this is the reason for a bug I am currently observing, when dealing with serialization and javascript, but I currently do not know, how to workaround it.

Basicaly I want to display a Birthdate via Json. I think because of the above reasons, everybuddy born before 6. April 1980, is born 1 hour erlier, which will be formatted as a day.

foo2 is serialized as /Date(298504800000)/, which is 1 hour to early, while foo2 is exactly as expected:

Serialized Date

My current Setup is:

  • SQL Server with Birthday as Date column
  • EF 6 which materializes it as DateTimeKind.Unspecified (Therefore Local assumed)
  • MVC5 JsonResult which gives it as shown as above
  • Clientside format via KendoUI {0:dd.MM.yyyy}

Is my assumption correct, this is a bug in the NET Framework? Do you have any Idea how to fix it?

Christian Gollhardt
  • 16,510
  • 17
  • 74
  • 111
  • Presumable just a missing datapoint in the used timezone database backing .Net (Either ICU or NLS depending on framework and plattform). But here it looks like you aren't really interest in the TImezone part and you might just fixed the Datetime Kind by calling [SpecifyKind](https://learn.microsoft.com/en-us/dotnet/api/system.datetime.specifykind?view=net-7.0) on the Datetime and setting it to Utc. – Ralf Jan 16 '23 at 19:48
  • The time is stored as UTC time. Globalization when you convert ToString converts to local time and adjusts for any changes like for SummerTime. I would check you timezone in windows to make sure to is set to German Timezone. It looks like in c# the default Globalization is set wrong./ – jdweng Jan 16 '23 at 20:15
  • When setting it to UTC, it is an hour to late (which will work for germany, but probably has problems in other timezones, with birthdays displayed on day later). `TimeZone.CurrentTimeZone` is Middle European Time, and Culture/UiCulture is German (de-DE). – Christian Gollhardt Jan 16 '23 at 20:37
  • 1
    @ChristianGollhardt: "Central European" timezone does not, and cannot, have the same summer time rules as all the individual countries, because they didn't use the same rules as each other prior to 1996. https://en.wikipedia.org/wiki/Central_European_Summer_Time#Period_of_observation You will need to set your locale to a Germany-specific timezone and not generic "Central European", in order to obtain the historical Germany rules for summer time. UICulture does not affect timezones. – Ben Voigt Jan 16 '23 at 20:55
  • Sorry if this is a dump question: The only relevant timezone I can find with `TimeZoneInfo.GetSystemTimeZones()` is `W. Europe Standard Time`, which is already set. Does it mean, there does not exits such timezone for Germany? Just wondering, because the Firefox Console seems to know it and therefore introduced the bug :( @BenVoigt – Christian Gollhardt Jan 16 '23 at 21:14

0 Answers0