XML Datum kann nicht 0.0 sein?

[QuickAndDirty]

Hallo, ich benutze SOAP zur Kommunikation zwischen Client und Server.
Nach Update auf Delphi 10.3 wirft diese Operation einen Fehler, aber NUR auf Android! In einem Windows kompilat geht es.
In 10.2 geht es auch auf Android.

Delphi-Quellcode:

  lastUpdate := TXSDatetime.Create;
  lastUpdate.AsDateTime := 0.0; //Das hier geht jetzt nicht mehr in Android...

[TiGü]

Kopiere dir doch mal die function DateTimeToXMLTime(Value: TDateTime; ApplyLocalBias: Boolean = True): InvString; aus der Unit Soap.XSBuiltIns direkt ins Projekt, reichere sie mit Log-Ausgaben an und versuche herauszufinden, welcher Schritt davon in Android nicht geht.
Scheitert es schon am FormatDateTime-Aufruf?

[QuickAndDirty]

Ich entwickele auf einem Android 4.1 Gerät :(
Der Fehler wird auf dem Smartphone von einem kollegen ausgegeben...
Ich warte noch auf ein neueres Smartphone....um das selbst debuggen zu können.
Bis jetzt steht fest: der Fehler kommt aus dieser Zeile

Delphi-Quellcode:

function DateTimeToXMLTime(Value: TDateTime; ApplyLocalBias: Boolean = True): InvString;
const
  Neg: array[Boolean] of string=  ('+', '-');
var
  Bias: Integer;
  tz:TTimeZone;
begin
  Result := FormatDateTime('yyyy''-''mm''-''dd''T''hh'':''nn'':''ss''.''zzz', Value); { Do not localize }
  tz := TTimeZone.Local;
  Bias := Trunc(tz.GetUTCOffset(Value).Negate.TotalMinutes);//<-------------HIER KOMMT DIE EXCEPTION HER
  if (Bias <> 0) and ApplyLocalBias then
  begin
    Result := Format('%s%s%.2d:%.2d', [Result, Neg[Bias > 0],                         { Do not localize }
                                       Abs(Bias) div MinsPerHour,
                                       Abs(Bias) mod MinsPerHour]);
  end else
    Result := Result + 'Z'; { Do not localize }
end;

Dank Delphi 10.3 bekomme ich dann irgendwann(hoffentlich in kürze)ein neues Entwicklungshandy, dann kann ich dem auf den Grund gehen...auch wenn ich davon ausgehe, dass es sinnlos ist, da Embarcadero es ja wieder so hinbiegen sollte, dass es funktioniert wie vorher, oder zumindest auf allen Plattformen gleich funktioniert.

[TiGü]

Hast du denn den Aufruf für den Bias mal aufgeschlüsselt und dir nach jeden Step Log-Ausgaben gemacht?
Eigentlich sehe ich in Tokyo keine Plattform-spezifischen Sachen, aber ich habe auch nicht gründlich nachgeschaut.

Delphi-Quellcode:

uses
   System.DateUtils, Soap.InvokeRegistry, System.TimeSpan;

function DateTimeToXMLTime(Value: TDateTime; ApplyLocalBias: Boolean = True): InvString;
const
  Neg: array[Boolean] of string= ('+', '-');
var
  Bias: Integer;
  tz:TTimeZone;
  Offset: TTimeSpan;
  NegOffset: TTimeSpan;
  TotalMinutsBias: Double;
begin
  Result := FormatDateTime('yyyy''-''mm''-''dd''T''hh'':''nn'':''ss''.''zzz', Value); { Do not localize }
  tz := TTimeZone.Local;
  Offset := tz.GetUTCOffset(Value);
  NegOffset := Offset.Negate;
  TotalMinutsBias := NegOffset.TotalMinutes;
  Bias := Trunc(TotalMinutsBias);
  if (Bias <> 0) and ApplyLocalBias then
  begin
    Result := Format('%s%s%.2d:%.2d', [Result, Neg[Bias > 0], { Do not localize }
                                       Abs(Bias) div MinsPerHour,
                                       Abs(Bias) mod MinsPerHour]);
  end else
    Result := Result + 'Z'; { Do not localize }
end;

[skoschke]

Warum ist der Formatstring so kryptisch?

FormatDateTime('yyyy-mm-dd''T''hh:nn:ss.zzz', Value)

ergibt doch ebenfalls z.B. "2019-03-05T15:15:23.123"

Ciao
Stefan

[TiGü]

Das musst du den ursprünglichen Embarcadero/Codegear/Borland-Mitarbeiter fragen.
Das steht schon so in Delpi XE drin.

[Schokohase]

Zitat:

Zitat von TiGü (Beitrag 1427003)

Das musst du den ursprünglichen Embarcadero/Codegear/Borland-Mitarbeiter fragen.
Das steht schon so in Delpi XE drin.

Weil der Entwickler sich die Dokumentation durchgelesen hat und sich dann (korrekt) für diese Variante entschieden hat.

Denn was bewirkt ein

Delphi-Quellcode:

:

im Format-String?

Zitat:

Zeigt als Uhrzeittrennzeichen das in der globalen Variablen TimeSeparator angegebene Zeichen an.

Und was bewirken die einfachen oder doppelten Anführungszeichen im Format-String?

Zitat:

In halbe oder ganze Anführungszeichen eingeschlossene Zeichen wirken sich nicht auf die Formatierung aus und werden wie eingegeben angezeigt.

Also um auf Nummer Sicher zu gehen werden ALLE Zeichen die sich niemals ändern dürfen entsprechend von Anführungsstrichen umschlossen.

Da hat sich tatsächlich der Entwickler mal etwas bei gedacht und nicht nur von der Tapete bis zur Wand (wie man es an manchen Stellen leider zu oft sieht).

[TiGü]

Wird wirklich Zeit, dass die Forensoftware der internationalen DP auch hier eingeführt wird. Ich möchte mich für die meisten deiner Beiträge per einfachen Klick bedanken. Immer kurz und knackig auf den Punkt und lehrreich dazu.
:thumb:

[Der schöne Günther]

Um nochmal zum eigentlichen Problem zurückzukommen: Was für eine Exception?

Wenn

Delphi-Quellcode:

Bias := Trunc(tz.GetUTCOffset(Value).Negate.TotalMinutes);

wirklich auf manchen Plattformen eine Exception auslöst, was könnte es sein? Ein Überlauf sodass das Ergebnis von

Delphi-Quellcode:

Trunc(..)

nicht mehr in einen Integer passt?


Vielleicht dass

Delphi-Quellcode:

TTimeZone.Local.GetUtcOffset(..)

irgendwas schräges liefert...

[TiGü]

Zitat:

Zitat von Der schöne Günther (Beitrag 1427009)

Um nochmal zum eigentlichen Problem zurückzukommen: Was für eine Exception?

Ja, stimmt!
Schade das QuickAndDirty das nicht mit dazu geschrieben hat.
Obwohl er schon so lange im Forum mit dabei ist und er deswegen eigentlich wissen müsste, dass es eine essentielle Information ist.
Ich debugge mich gerade durch die Aufrufe durch.

Delphi-Quellcode:

System.DateUtils.TLocalTimeZone.TimeZoneChanged
System.DateUtils.TLocalTimeZone.GetCachedChangesForYear(2019)
System.DateUtils.TLocalTimeZone.DoGetOffsetsAndType(43554,96875,4676218962906710016,18721139674706580,lttStandard)
System.DateUtils.TTimeZone.GetUtcOffsetInSeconds(43554,96875,False)

Die Funktion TimeZoneChanged hat in meiner Version $IF-Defs für Windows, MacOS und POSIX. Ich nehme an, Android wird als POSIX Betriebssystem abgehandelt, da im Kern ein Linux.
Da wird bspw. localtime_r aufgerufen (https://linux.die.net/man/3/localtime_r).

In TTimeZone.GetUtcOffsetInSeconds besteht die Möglichkeit, dass eine ELocalTimeInvalid-Exception geworfen wird.
TTimeSpan.GetScaledInterval: EArgumentException.
TTimeSpan.Negate: EIntOverflow.
Trunc wird am Ende und intern beim Durchlauf ein-zweimal aufgerufen. Da wäre ggf. auch eine Fehlerquelle, falls die Umsetzung für Android/Linux fehlerhaft ist (

Delphi-Quellcode:

{       functions & procedures that need compiler magic }

)