AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Delphi XML Datum kann nicht 0.0 sein?

XML Datum kann nicht 0.0 sein?

Ein Thema von QuickAndDirty · begonnen am 4. Mär 2019 · letzter Beitrag vom 13. Mär 2019
Antwort Antwort
Seite 2 von 2     12
QuickAndDirty

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
1.518 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#11

AW: XML Datum kann nicht 0.0 sein?

  Alt 6. Mär 2019, 14:28
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"
Andreas
#PerfMatters
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
2.108 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#12

AW: XML Datum kann nicht 0.0 sein?

  Alt 6. Mär 2019, 14:36
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).';
  Mit Zitat antworten Zitat
QuickAndDirty

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
1.518 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#13

AW: XML Datum kann nicht 0.0 sein?

  Alt 7. Mär 2019, 10:42
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]
Andreas
#PerfMatters

Geändert von QuickAndDirty ( 7. Mär 2019 um 10:46 Uhr)
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
2.108 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#14

AW: XML Datum kann nicht 0.0 sein?

  Alt 7. Mär 2019, 10:52
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.
  Mit Zitat antworten Zitat
Benutzerbild von Sherlock
Sherlock

Registriert seit: 10. Jan 2006
Ort: Offenbach
3.261 Beiträge
 
Delphi 10.3 Rio
 
#15

AW: XML Datum kann nicht 0.0 sein?

  Alt 7. Mär 2019, 10:53
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
Geändert von Sherlock (Morgen um 16:78 Uhr) Grund: Weil ich es kann
  Mit Zitat antworten Zitat
QuickAndDirty

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
1.518 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#16

AW: XML Datum kann nicht 0.0 sein?

  Alt 13. Mär 2019, 16:24
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...
Andreas
#PerfMatters

Geändert von QuickAndDirty (13. Mär 2019 um 16:40 Uhr)
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
983 Beiträge
 
Delphi 7 Professional
 
#17

AW: XML Datum kann nicht 0.0 sein?

  Alt 13. Mär 2019, 16:45
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.
  Mit Zitat antworten Zitat
QuickAndDirty

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
1.518 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#18

AW: XML Datum kann nicht 0.0 sein?

  Alt 13. Mär 2019, 17:07
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!

Andreas
#PerfMatters

Geändert von QuickAndDirty (13. Mär 2019 um 17:22 Uhr)
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
983 Beiträge
 
Delphi 7 Professional
 
#19

AW: XML Datum kann nicht 0.0 sein?

  Alt 13. Mär 2019, 17:46
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?

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?
  Mit Zitat antworten Zitat
QuickAndDirty

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
1.518 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#20

AW: XML Datum kann nicht 0.0 sein?

  Alt 13. Mär 2019, 21:56
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.
Andreas
#PerfMatters
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:55 Uhr.
Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf