TJSONMarshal / TJSONUnMarshal böse Falle

[Rollo62]

Ich frage mich seit geraumen warum eine App plötzlich Timestamps falsch berechnet.
Der Grund war das Encoding / Decoding mit TJSONMarshal / TJSONUnMarshal.

Das hat bis dato gut funktioniert, Object zu String, und zurück, aber seit womöglich 10.1 Berlin gab es da plötzlich Probleme.
Normalerweise debugge ich nicht tief in die System Sourcen, aber hier musste es mal wieder sein :(

Der Grund war das TJSONMarshal / TJSONUnMarshal anscheinend neuerdings unterschiedliche IsDateTimeUTC settings per Default eingestellt haben.
Kann jetzt nicht genau sagen seit wann ...

Die Lösung war das explizit mit anzugeben, um die Konvertierungen kompatibel zu machen, also

Delphi-Quellcode:

LMar.DateTimeIsUTC := True;

für Marshal/Unmarshal:

Delphi-Quellcode:

function TParcel.InternalMarshal_ToString : String;
var
  LMar : TJSONMarshal;
begin

  LMar := TJSONMarshal.Create();    // This doesn't correctly set DateTimeUTC by default

  try
      LMar.DateTimeIsUTC := True;  // !!! Important to ensure same Coding/Decoding

      Result := LMar.Marshal(Self).ToString; // as TJSonObject;

  finally
      LMar.Free;
  end;

end;



function TParcel.InternalUnmarshal_FromObject(value: TJSONObject): TParcel;

var
  LMar: TJSONUnMarshal;

begin
    Result := nil;

    if not Assigned( value ) then
        Exit;

    LMar := TJSONUnMarshal.Create();  // This sets DateTimeIsUTC internally by default

    try
        LMar.DateTimeIsUTC := True;  // !!! Important to ensure same Coding/Decoding

        ...
        ...
        ...


    finally
        LMar.Free;
    end;
end;

Wenn es nicht gleich gesetzt wird kann es zu einer Zeitdifferenz dei Encode/Decode kommen von 2:00h.
Das ist definitiv nicht das was ich erwarten würde :stupid:

Rollo

[Der schöne Günther]

Traue niemals der Delphi-RTL, schreibe Unit-Tests! :warn:

Zumindest in 10 Seattle ergibt ein

Delphi-Quellcode:

EncodeDateTime(1988, 10, 21, 17, 45, 39, 999)

im JSON noch ein

Delphi-Quellcode:

'1988-10-21T17:45:39.999Z'

.

[Uwe Raabe]

Kannst du dafür noch einen Eintrag in QP erstellen?

[Der schöne Günther]

Ich verstehe das Problem noch nicht. Ein TDateTime ist lokale Zeit, nicht UTC. Von TObject nach JSON nehmen wir kein UTC an, von Json nach TObject schon. Ich denke, das ist doch so richtig, oder?

Delphi-Quellcode:

program UTCMarshalTest;

{$APPTYPE CONSOLE}
{$R *.res}

uses
  System.SysUtils,
  System.DateUtils,
  System.Types,
  System.Json,
  REST.JsonReflect,
  Unit1 in 'Unit1.pas';

procedure p();
var
   marshal: TJsonMarshal;
   unmarshal: TJSONUnMarshal;
   myObject: TMyObject;
   timestamp: TDateTime;
   myObject2: TMyObject;
begin
   marshal := nil; unmarshal := nil;
   myObject := nil; myObject2 := nil;
   try
      marshal := TJSONMarshal.Create();
      unmarshal := TJSONUnMarshal.Create();

      myObject := TMyObject.Create();
      timestamp := EncodeDateTime(2017, 10, 02, 10, 28, 44, 123);
      myObject.FTimeStamp := timestamp;

      myObject2 := unmarshal.CreateObject(
         TMyObject,
         marshal.Marshal(myObject) as TJsonObject
      ) as TMyObject;

      Assert(
         CompareDateTime(myObject.FTimeStamp, myObject2.FTimeStamp)
         =
         System.Types.EqualsValue
      );
   finally
      marshal.Free(); unmarshal.Free();
      myObject.Free(); myObject2.Free();
   end;
end;

begin
   try
      p();
   except
      on E: Exception do
         Writeln(E.ClassName, ': ', E.Message);
   end;
   WriteLn(sLineBreak, 'end.');
   ReadLn;
end.

[Uwe Raabe]

Das Problem ist, daß dein Code unter Tokyo eine EAssertionFailed-Exception auslöst.

[Der schöne Günther]

Oh, ok. Unter Seattle läuft alles korrekt durch. Ich dachte er sei verwirrt dass

Delphi-Quellcode:

marshal

und

Delphi-Quellcode:

unmarshal

nicht die gleiche Datums/UTC-Eigenschaften hatten.

[Rollo62]

Hallo Uwe,

Zitat:

Kannst du dafür noch einen Eintrag in QP erstellen?

Bin mir nicht sicher ob das jetzt ein Bug ist oder nicht.
Man muss es halt "vollständig" konfigurieren.

Rollo

[Rollo62]

Hallo Günther,

Zitat:

ch verstehe das Problem noch nicht. Ein TDateTime ist lokale Zeit, nicht UTC. Von TObject nach JSON nehmen wir kein UTC an, von Json nach TObject schon. Ich denke, das ist doch so richtig, oder?

Das Problem ist ich ein Objekt zu JSON mit Marshal encodiere , und
dann dieses JSON wieder zu einem Objekt mit Unmarshal dekodiere.

Wenn da im Objekt ein TDateTime Feld drin ist wird mit Marshal eine UTC Korrektur gemacht
und dann bei Unmarshal aber nicht (oder umgekehrt, habs jetzt gerade nicht nachgesehen).
Standardmässig wird das ISOEncode benutzt, welches UTC berücksichtigt.

Das Ergebnis-Objekt hat dann danach zum Ausgangs-Objekt je nach Zeitzone eine Differenz von z.B. +2:00.

Es muss im Marshal/Umarshal DateTimeIsUTC = True/False; expliziert gesetzt werden das ich mit oder ohne Korrektur arbeiten möchte, jedenfalls das es bei Beiden gleich sein sollte.

Rollo

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1382445)

Bin mir nicht sicher ob das jetzt ein Bug ist oder nicht.
Man muss es halt "vollständig" konfigurieren.

Das Verhalten unter Tokyo ist zumindest ein Anderes als unter Seattle und Berlin. Das ist in jedem Fall einen QP-Eintrag wert (Regression). Der Fehler kommt durch einen Bugfix in

Delphi-Quellcode:

TISODateTimeInterceptor

zustande, der eine entsprechende Anpassung in

Delphi-Quellcode:

TJSONMarshal.Create

erfordert. Insofern ist dein Anwendungsfall ein wichtiger Testcase.

Berlin:

Delphi-Quellcode:

constructor TISODateTimeInterceptor.Create(ADateTimeIsUTC: Boolean);
begin
  ConverterType := ctString;
  ReverterType := rtString;
  FDateTimeIsUTC := true;
end;

Tokyo:

Delphi-Quellcode:

constructor TISODateTimeInterceptor.Create(ADateTimeIsUTC: Boolean);
begin
  ConverterType := ctString;
  ReverterType := rtString;
  FDateTimeIsUTC := ADateTimeIsUTC;
end;

[Rollo62]

Hallo Uwe,

hier der QP-Eintrag, hab mal ne freie Minute gefunden.

Rollo

[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