XML Datum kann nicht 0.0 sein?

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

Zitat von QuickAndDirty (Beitrag 1427082)

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

Also jene welche?

Delphi-Quellcode:

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

[QuickAndDirty]

Ja!
WoW!
Aber warum wird diese Exception auf Delphi 10.3 Android geworfen?

[OT]
mein ADB install
bleibt in der Zeile
hängen
ADB.exe D 03-06 17:17:47 2616 2640 commandline.cpp:372] copy_to_file(2048 -> 2049)
:(
Wieso macht das telefon sowas...

Und das wurde extra angeschafft damit ich den scheiß datums fehler debuggen kann...jetzt schlage ich mich seit tagen damit herum...die app per ADB(oder delphi) auf das phone zu bekommen.
Manchmal hasse ich den Scheiß.
[/O]

[TiGü]

Kenne mich damit wirklich nicht aus, aber mir ist in Erinnerung geblieben, wenn sowas nicht geht, dass man per Android Studio ein leeres Projekt erzeugen und rüberspielen soll. Die Suchfunktion hier in der DP sollte dir weiterhelfen.

[Sherlock]

Zitat:

Zitat von TiGü (Beitrag 1427006)

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:

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.

[QuickAndDirty]

Lustig...

Delphi-Quellcode:

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

versucht auch den "Localbias" und die Zeitzone zu ermitteln... man weiß ja nie wie sehr UTC von UTC abweicht....
Und stürzt dabei genauso ab....

@Delphinarium ich versuche dafür zu sorgen dass

Delphi-Quellcode:

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

in Delphi Rio weiterhin funktioniert...wie in Delphi Tokyo
:(

irgendwo dadrin passiert das

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);
  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;

TTimZone.GetUTCOffset versucht aus einem Cache die Offsets für Daylight savingstime zu ermitteln... Weil sich sowas Jahr für Jahr und Land für Land ändert...
Dabei dann schmeißt Embarcadero mit Fehlern (Localtimetype =lttInvalid) für 1899 um sich :(
Das war vorher nicht so!

:(

[Delphi.Narium]

DateTimeToUnix und UnixToDateTime (aus DateUtils bei Delphi 7) zur Konvertierung zwischen den "Welten" nutzen?

Die Konvertierung von Unix nach TDateTime scheint mir damit plausibel zu sein, aber von DateTime nach Unix nicht. Aus dem 30.12.1899 wird als Unix 2085805696, das zurückverwandelt ergibt aber 05.02.2036 06:28:16.

Delphi-Quellcode:

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

schon klar, aber 0 ist nunmal < 1970 und deshalb fliegt Dir das "irgendwie" um die Ohren.

Der 01.01.1970 ist als TDateTime = 25569 das entspricht also 0 als Unix.

Wenn es Dir darum geht z. B. kein Datum = 0 in "beiden Welten" zu ermöglichen, so musst Du da wohl die 25569 irgendwie als Korrekturwert einbauen.

Ok, andererseits: Wo ist der Cache? Ist sein Inhalt unter Android (in der speziellen Delphiversion) eventuell fehlerhaft befüllt?

Wo kommst Du mit dem Debugger hin, wenn Du hier noch weiter durchsteppst?

Delphi-Quellcode:

if After(AChanges.FStartOfDST) and BeforeSum(AChanges.FStartOfDST, LDstSave) then ///<------------ DANN HIER DER Ausstieg Exit(lttInvalid);

After und BeforeSum müssen doch auch noch irgendwas machen, um den Schluss ziehen zu können, dass das Datum 0 / 30.12.1899 lttInvalid ist.

Und hier müssen sich irgendwelche Unterschiede bei den Delphiversionen ergeben. Hast Du die Möglichkeit mal in zwei IDEs quasi parallel mit dem Debugger dadurchzugehen, um so die Problemursache zu finden?

Hast Du die Quellen der unterschiedlichen Delphiversionen und kannst die betroffenen Units mal mit 'nem Diff vergleichen?

[QuickAndDirty]

Fuck me!
Klar ich habe beide Delphis in Virtuellen maschienen, und zwei smartphones mit jeweils passendem Android

0.0 mag 1970 sein, aber GetUTCOffset(Value) rechnet mit 1899 weiter. nicht mit 1970...

Ich gucke mal wie das in 10.2 läuft.