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.

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.

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).

First, timezone is present (that's what the "Europe/Berlin" is). CEST is not a timezone. CET (interpreted specifically as the winter offset) is not a timezone.

The object DateObject[List[2022, 10, 30, 1, 30, 0], "Instant", "Gregorian", "Europe/Berlin"] is given an unambiguous definition by Mathematica (the moment earlier in time). So there's no lack of rigor here. What's ambiguous is what it means to to say it's 1:30 in the local time when the transition out of daylight saving is happening. This isn't a software ambiguity, it's a real world ambiguity. If I were to say "I'll meet you on the corner at 1:30 am", there are two possible times that I might show up. Let's imagine that you hadn't started with the GMT time and followed that with a TimeZoneConvert, but instead you started with your local Central European time of "1:30 am"...what would you expect Mathematica to do with that? Pause and put up a dialog asking the user to specify which time they meant? If you intended the time to be the later time, the only way to get the TimeZoneConvert back to GMT to work would be to tell Mathematica that you actually meant a different time. You'd have to do some sort of date add of 1 hour. Or you'd just work in GMT from the start. Local time representations simply have no way to disambiguate that hour of time during the transition out of daylight saving. It's up to you do provide that disambiguation, because you're the one that knows what time you're talking about.

I understand that you wish that there was some way to preserve the provenance of the date-time info as you go through TimeZoneConvert conversions. For good or bad, that's just not how it works. You can consider it a bug if you want to, but it's not inherently wrong.