XML Datum kann nicht 0.0 sein?

[TiGü]

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

[Schokohase]

Zitat von TiGü:

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

[Der schöne Günther]

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

Wenn 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 Trunc(..) nicht mehr in einen Integer passt?


Vielleicht dass TTimeZone.Local.GetUtcOffset(..) irgendwas schräges liefert...

[TiGü]

Zitat von Der schöne Günther:

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 ({       functions & procedures that need compiler magic } )

[QuickAndDirty]

Ich würde gerne mehr dazu sagen, aber ich versuche seit dem letzten Post Delphi 10.3 mit dem NOKIA 6.1(Android 9) zum debuggen zu verbinden...
leider bleibt die IDE dann in der Anzeige

"Installieren von"
c:\MeinOrdner\Meine.apk

hängen....
Und ich bekomme das Handy(Sony Z3) von dem Kollegen nicht welches ja ginge...

Aus dem kopf weiß ich die Exception nicht mehr genau,
aber es hieß irgendwie "Datum liegt vor der Sommerzeit"

[TiGü]

Zitat von QuickAndDirty:

Aus dem kopf weiß ich die Exception nicht mehr genau,
aber es hieß irgendwie "Datum liegt vor der Sommerzeit"

Also jene welche?

SLocalTimeInvalid = 'Die angegebene "%s" lokale Uhrzeit ist ungültig (befindet sich im fehlenden Zeitraum vor der Sommerzeit).';

[Sherlock]

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

Sehe ich genauso!

Sherlock

[QuickAndDirty]

Yay, ich kann wieder debuggen....

Der Fehler wird vermutlich(=ich bin nicht sicher) von dem Aufruf der Plattformspezifischen Methode

System.Dateutils.TlocalTimezone.GetChangesForYear

ausgelöst.




WIN32 kann 1899

Delphi-Quellcode:

  
{ Win32 can't handle dates outside this range }
  if (AYear <= 1601) or (AYear > 30827) then
    exit;

POSIX kann 1899 nicht

Delphi-Quellcode:

  if (SizeOf(LongInt) = 4) and ((AYear < 1970) or (AYear > 2037)) then
    Exit; // Not supported

Bin gerade noch mitten drin... mal sehen ob es das ist...

Also System.Dateutils.TlocalTimezone.GetChangesForYear Fügt einen Record in den LChanges Cache hinzu für 1899
Lchanges ist der Cache für YearlyChanges....was auch immer das heist

Dieser record sollte eigentlich komplett leer sein so wie ich das verstanden habe, ODER?

Leider scheint das nicht der fall zu sein.

Die Funktion GETTYPE findet dann den YearlyChangesRecord doof.

Delphi-Quellcode:

function TLocalTimeZone.GetType(const ADateTime: TDateTime; const AChanges: TYearlyChanges): TLocalTimeType;

 function After(const Point: TDateTime): Boolean;
 begin
   Result := CompareDateTime(ADateTime, Point) >= 0;
 end;

 function AfterSum(const Point: TDateTime; const Sum: Int64): Boolean;
 begin
   Result := CompareDateTime(ADateTime, IncSecond(Point, Sum)) >= 0;
 end;

 function Before(const Point: TDateTime): Boolean;
 begin
   Result := CompareDateTime(ADateTime, Point) < 0;
 end;

 function BeforeSum(const Point: TDateTime; const Sum: Int64): Boolean;
 begin
   Result := CompareDateTime(ADateTime, IncSecond(Point, Sum)) < 0;
 end;

var
  LDstSave: Int64;
begin
  { Default to normal }
  Result := lttStandard;

  { Calculate the save }
  LDstSave := (AChanges.FBiasWithDST - AChanges.FBias);//<--- DAS HIER MÜSSTE 0 Ergeben und alles wäre gut ????  Result := lttStandard;

  { Check only if we have a DST bias ... }
  if LDstSave <> 0 then///<------------ LEIDER geht das Programm hier rein :(
  begin
    { NOTE: Apparently there are Countries that use inverse DST rules. This means that instead
      of adjusting their clocks +xxx time in the summer/winter, they adjust by -xxxx at the opposite
      season. In this particular case, LDstSave would be a negative number and thus the invalid/ambiguous
      rules change from start -> end to end -> start.
    }
    if LDstSave > 0 then///<------------ LEIDER HIER AUCH
    begin
      { Invalid time between transitions (Normal Daylight) }
      if After(AChanges.FStartOfDST) and BeforeSum(AChanges.FStartOfDST, LDstSave) then ///<------------ DANN HIER DER Ausstieg Exit(lttInvalid);
        Exit(lttInvalid);

      { Ambiguous time between transitions (Normal Daylight) }
      if Before(AChanges.FEndOfDST) and AfterSum(AChanges.FEndOfDST, -LDstSave) then
        Exit(lttAmbiguous);
    end else
    begin
      { Invalid time between transitions (Inverse Daylight) }
      if Before(AChanges.FStartOfDST) and AfterSum(AChanges.FStartOfDST, LDstSave) then
        Exit(lttInvalid);

      { Ambiguous time between transitions (Inverse Daylight) }
      if After(AChanges.FEndOfDST) and BeforeSum(AChanges.FEndOfDST, -LDstSave) then
        Exit(lttAmbiguous);
    end;

    { Northern Hemisphere OR "Winter Daylight" }
    if (CompareDateTime(AChanges.FStartOfDST, AChanges.FEndOfDST) < 0) and
       (After(AChanges.FStartOfDST) and Before(AChanges.FEndOfDST)) then
      Exit(lttDaylight);

    { Southern Hemisphere OR "Summer Daylight" }
    if (CompareDateTime(AChanges.FStartOfDST, AChanges.FEndOfDST) > 0) and
       (After(AChanges.FStartOfDST) or Before(AChanges.FEndOfDST)) then
      Exit(lttDaylight);
  end;
end;

Ihr habt nicht zufällig ne idee wie man das in ordnung bringt?


1971 als basisdatum nutzen?

Ich brauche 1899 aus Kompatibilitätsgründen zu Firebird und TDatetime in anderen programmen...

[Delphi.Narium]

Unixtimestamp = Sekunden seit 1.1.1970 00:00:00 UTC

Unixtimestamp = Integer

Max(Integer) = 2.147.483.647

1 Jahr = 31.556.926 Sekunden (365,24 Tage)

2.147.483.647 / 31.556.926 = 68,051103805231219289229882530383

1.1.1970 + 68 = ca. 2037 bis zum Überlauf.

Wenn ich die zitierte Quelltextzeile recht verstehen, müsste die Berechnung aber, soweit LongInt größer oder kleiner als 4 Byte groß ist, funktionieren.

Definiere doch LongInt mal um, z. B. auf LongInt = Byte. Dann sollte das doch gehen oder?

Ok, das ist jetzt böse, aber:

Der Sinn der zitierten Quelltextzeile erscheint mir doch eher fraglich. Und wenn daraus "nicht näher zu ergründende" Folgefehler resultieren, scheint mir das eher wahrscheinlich.