Group Abstract

Message Boards

WOLFRAM COMMUNITY

3.7K Views

7 Replies

4 Total Likes

View groups...

Follow this post

Share this post:

GROUPS:

Wolfram Language Units

Daylight saving time - timezone conversion trouble

Bernd Günther

Posted 2 years ago

Hi, in the last week of October, when switching back from daylight saving time to normal time, the hour between 2am and 3am exists twice, with different offsets. Here Mathematica mixes up: stmptbl = {DateObject[{2022, 10, 29, 23, 30, 0}, TimeZone -> 0], DateObject[{2022, 10, 30, 0, 30, 0}, TimeZone -> 0], DateObject[{2022, 10, 30, 1, 30, 0}, TimeZone -> 0], DateObject[{2022, 10, 30, 2, 30, 0}, TimeZone -> 0]} stmptbl2 = TimeZoneConvert[#, "Europe/Berlin"] & /@ stmptbl The third entry in the result {Sun 30 Oct 2022 01:30:00CEST, Sun 30 Oct 2022 02:30:00CEST, Sun 30 Oct 2022 02:30:00CEST, Sun 30 Oct 2022 03:30:00CET} is wrong: this is no longer daylight saving time, but standard time ("winter time"). For the reverse conversion TimeZoneConvert[#, 0] & /@ stmptbl2 you obtain: {Sat 29 Oct 2022 23:30:00GMT, Sun 30 Oct 2022 01:30:00GMT, Sun 30 Oct 2022 01:30:00GMT, Sun 30 Oct 2022 02:30:00GMT} Here the second entry is wrong and deviates by one hour. I assume this is a bug (or rather: two bugs). Can anyone suggest a workaround? Yours, Bernd.

Hi,

in the last week of October, when switching back from daylight saving time to normal time, the hour between 2am and 3am exists twice, with different offsets. Here Mathematica mixes up:

stmptbl = {DateObject[{2022, 10, 29, 23, 30, 0}, TimeZone -> 0], 
  DateObject[{2022, 10, 30, 0, 30, 0}, TimeZone -> 0], 
  DateObject[{2022, 10, 30, 1, 30, 0}, TimeZone -> 0], 
  DateObject[{2022, 10, 30, 2, 30, 0}, TimeZone -> 0]}

stmptbl2 = TimeZoneConvert[#, "Europe/Berlin"] & /@ stmptbl

The third entry in the result

{Sun 30 Oct 2022 01:30:00CEST,
Sun 30 Oct 2022 02:30:00CEST,
Sun 30 Oct 2022 02:30:00CEST,
Sun 30 Oct 2022 03:30:00CET}

is wrong: this is no longer daylight saving time, but standard time ("winter time"). For the reverse conversion

TimeZoneConvert[#, 0] & /@ stmptbl2

you obtain:

{Sat 29 Oct 2022 23:30:00GMT,
Sun 30 Oct 2022 01:30:00GMT,
Sun 30 Oct 2022 01:30:00GMT,
Sun 30 Oct 2022 02:30:00GMT}

Here the second entry is wrong and deviates by one hour.

I assume this is a bug (or rather: two bugs). Can anyone suggest a workaround?

Yours,

Bernd.

POSTED BY: Bernd Günther

7 Replies

Sort By:

Eric Rimbey

Posted 2 years ago

And just for kicks: TimeZoneOffset["Europe/Berlin", {2023, 3, 26, 2, 30, 0}] `{}` So, Mathematica doesn't commit to an offset for this time specification. Also: TimeZoneConvert[DateObject[{2023, 3, 26, 1, 30, 0}, TimeZone -> "Europe/Berlin"], "GMT"] `DateObject[List[2023, 3, 26, 0, 30, 0], "Instant", "Gregorian", "GMT"]` TimeZoneConvert[DateObject[{2023, 3, 26, 2, 30, 0}, TimeZone -> "Europe/Berlin"], "GMT"] `DateObject[List[2023, 3, 26, 1, 30, 0], "Instant", "Gregorian", "GMT"]` TimeZoneConvert[DateObject[{2023, 3, 26, 3, 30, 0}, TimeZone -> "Europe/Berlin"], "GMT"] `DateObject[List[2023, 3, 26, 1, 30, 0], "Instant", "Gregorian", "GMT"]` These seem all reasonable choices. Your A/B convention doesn't fix the inverse problem of only 23 hours during the day when daylight saving begins, but Mathematica does something sensible. Really, Mathematica has all of the knowledge that you need to do your time-related computations correctly.

POSTED BY: Eric Rimbey

Eric Rimbey

Posted 2 years ago

POSTED BY: Eric Rimbey

Eric Rimbey

Posted 2 years ago

POSTED BY: Eric Rimbey

Eric Rimbey

Posted 2 years ago

If there is a bug here, I'd say that it's just a trivial one with regard to presentation. Your objection seems to be that `Sun 30 Oct 2022 02:30:00CEST` is asserting that this time is in "daylight saving time" instead of "standard time". But standard time and daylight saving time aren't attributes of time. They are standards for determining offsets for local time representations. So, in the local time of Berlin (let's say for simplicity), the clocks would indeed read 2:30. The `FullForm` of that particular date object is DateObject[List[2022, 10, 30, 2, 30, 0], "Instant", "Gregorian", "Europe/Berlin"] The notion of "standard" or "daylight saving" is absent (as is day of week). The display of "CEST" (and "Sun") was just a presentation issue, a choice that it made for showing you the data. That attribute had to be derived--it wasn't actually part of the raw data. You also assert that the conversion back to GMT is a bug. But of course we have a problem here. We don't have a nice one-to-one relationship in our original conversion from GMT to CE(S)T, so the distinction between the second and third times is lost. Now maybe you'd prefer that a `DateTime` object should store unix time or something absolute like that and have all other timezone related behaviors be matters of presentation. But that's not how Wolfram did it. I assume that there is a legitimate reason for their choice.

POSTED BY: Eric Rimbey

Eric Rimbey

Posted 2 years ago

Just a clarification, I was applying the convention where I live, which is to set the clocks back from 2am to 1am. It sounds like your convention is to set the clocks back from 3am to 2am. So, my specific examples might not make sense.

POSTED BY: Eric Rimbey

Bernd Günther

Posted 2 years ago

No, I do not agree. The day in question is 25h long, but your clock holds only 24h - so there must be something special here. The hour between 2am and 3am is run twice, and for distinction the first run is labelled "A" and the second "B". So a valid conversion of DateObject[{2022, 10, 30, 0, 30, 0}, TimeZone -> 0] to "Europe/Berlin" would be 2022-10-30 02A:30:00 "Europe/Berlin" equivalently 2022-10-30 02:30:00 CEST equivalently 2022-10-30 GMT+2. A valid conversion of DateObject[{2022, 10, 30, 1, 30, 0}, TimeZone -> 0] to "Europe/Berlin" would be 2022-10-30 02B:30:00 "Europe/Berlin" equivalently 2022-10-30 02:30:00 CET equivalently 2022-10-30 GMT+1. The convention chosen by mathematica is not well defined, a random choice has been made. This will neccessarily lead to trouble, as I have shown when converting back to timezone 0. In addition to that, with mathematica's current convention, the "B"-hour cannot be represented at all in "Europe/Berlin".

POSTED BY: Bernd Günther

Bernd Günther

Posted 2 years ago

Hi Eric, no, my objection is that CEST equals GMT+2 and CET equals GMT+1, therefore the third entry above is definitely wrong (timezone is a [neccessary for completeness] attribute of a datetime object, no matter how you represent it). Futher, the specification "DateObject[List[2022, 10, 30, 2, 30, 0], "Instant", "Gregorian", "Europe/Berlin"]" is ambiguous, and if mathematica represents the object internally like that they won't be able to fix this. For a well defined representation in this case you need offsets. Unfortunately, this means that I have to do my conversion manually, and as it appears, mathematica contains more timezone bugs ...

POSTED BY: Bernd Günther

Reply to this discussion

Reply Preview

Attachments

Remove Add a file to this post

Follow this discussion

or Discard

Feedback