TJSONMarshal / TJSONUnMarshal böse Falle

[Uwe Raabe]

Ich bin mir nicht sicher, ob die Erklärung nicht irreführend ist.

Delphi-Quellcode:

FDateTimeIsUTC := true;

war der ursprüngliche Code (siehe Berlin in meinem Post) und hat implizit dafür gesorgt, daß TJSONMarshal/TJSONUnMarshal mit derselben Einstellung arbeiteten und das korrekte Ergebnis brachten. Allerdings wurde die jeweilige Einstellung von DateTimeIsUTC gar nicht ausgewertet (der Create-Parameter wurde ja ignoriert).

In Tokyo ist das geändert worden (siehe Tokyo in meinem Post) und es wird der übergebene Parameter verwendet, was auch vollkommen richtig ist. Das bedeutet aber, daß in TJSONMarshal/TJSONUnMarshal jeweils diese Werte auch passend gesetzt werden müssen (also beide True oder beide False). Das ist ja auch die Beobachtung, die du bereits im Eingangspost gemacht hast.

Der Fehler ist also nicht das

Delphi-Quellcode:

FDateTimeIsUTC := ADateTimeIsUTC

im

Delphi-Quellcode:

TISODateTimeInterceptor.Create

(was ja nur das falsche Verhalten korrigiert), sondern die fehlende Initialisierung von

Delphi-Quellcode:

DateTimeIsUTC := true

im

Delphi-Quellcode:

TJSONMarshal.Create

, um mit TJSONUnMarshal synchron zu sein.

Vermutlich sollte diese Initialisierung auch nicht in

Delphi-Quellcode:

TJSONMarshal.Create

gemacht werden, sondern in

Delphi-Quellcode:

TTypeMarshaller<TSerial>.Create

, wo das DateTimeIsUTC ja bereits deklariert wird. Gleichzeitig sollte das DateFormat auch dort initialisiert werden, und zwar ebenfalls synchron zu der Initialisierung in TJSONUnMarshal.

Noch besser wäre es sogar, wenn man sowohl DateFormat als auch DateTimeIsUTC bereits in der Basisklasse TMarshalUnmarshalBase deklariert und initialisiert. Dann würde das Problem gar nicht auftauchen.

Ich habe mir mal erlaubt, den Text entsprechend anzupassen und auch einen Verweis auf den QP-Eintrag zu ergänzen, der dem Fix zugrunde liegt.

[Rollo62]

Ok, sorry.
Hatte ich genau andersrum gelesen Berlin <-> Tokyo.
Sollte Emba aber so oder so klar sein.

Rollo