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

Your A and B distinctions would be nice, but I'm not aware of any time standard that uses something like that. You could just implement it yourself if it's that important to you. But the fact that Mathematica doesn't use it doesn't constitute a bug.

And it's not a matter of Mathematica not understanding the daylight saving convention. Look at this:

TimeZoneOffset["Europe/Berlin", {2022, 10, 30, 2, 30, 0}]

{2, 1}

So, Mathematica knows that there is ambiguity here.

And if we had your A/B convention, then the user would need to apply that convention when they input date-times directly (as opposed to doing a conversion from GMT). Doesn't seem particularly elegant to me.

Again, it's perfectly reasonable for you to want a date-time framework to keep track of all date-times in some absolute format regardless of timezone conversions or other manipulations. But that's not what Mathematica has chosen to implement. That's not a bug, is a design choice. The more I think about it, the more I think it was the right choice, because otherwise the system would have to try to resolve ambiguities itself without any context. The way it is now in Mathematica, the user, the one with knowledge of which date-times they want to specify, is the one with the responsibility to resolve ambiguities.

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