GLib und die Schaltsekunden?
Wie kommt es, dass quasi das ganze Internet keine Schaltsekunden kennt...?
GLib sagt ausdrücklich, dass sie ganz absichtlich keine Schaltsekunden berücksichtigen, selbst wenn das Betriebssystem es unterstützt – wie beispielsweise Linux mit POSIX-Zoneinfo –, dann rechnet GLib trotzdem selbst nochmal alles ganz genau falsch nach, so dass man die Genauigkeit von Zeitdifferenzen gleich vergessen kann.
Javascript ist damit auch Schrott und damit auch gleich Android.
Google „verschmiert“ Schaltsekunden tagelang, indem die Sekunden alle etwas länger/kürzer werden (🤣): Leap Smear.
Selbst Windows kann Schaltsekunden – schätz' ich mal, ich darf ja keine Microsoft-Produkte nutzen. 😋
Wie kommt so etwas? Ich meine: Die Mathematik ist total einfach und das Problem ist seit Jahrzehnten im Linux-Umfeld gelöst, bloß GLib schnallt es nicht...
6 Antworten
Bei einem solchen Problem musst du dir je nach deinem Anwendungsfall überlegen, in was für einem Format du deine Zeitangabe speichern willst und wie du das Format konvertierst.
und diese GLib wird es wohl nie lernen... oder?
so bekomm ich iwi immer komisch Umrechnungen, wenn ich mein Geburtsdatum in ein Internetformular eingebe... dann steht da meist der Vortag... total komisch... manchmal wird es sogar noch schlimmer, wenn das Geburtsdatum mehrfach in Sekunden seit Anfang 1970 „umgerechnet“ wird... 😋
ich weiß nich... ist echt ärgerlich, wenn man am Flughafen steht und die einem erzählen, dass man nich der echte Luke ist... 😋
ich würd fast lieber diese schmierige Google Zeit in der Firma und privat haben...
Mein phone hat er nich „richtig“ hinbekommen... mit dem mache ich jez immer die Buchungen... 😋
OK, ist das wirklich passiert, dass die Buchung einfach einen Tag falsch lag, weil sich die Zeit nicht hat richtig einstellen lassen?
Für so etwas müsste ja dann die Firma verantwortlich sein.
Mir erklärt sich nicht, warum Schaltsekunden verantwortlich sein sollen. Denn der Geburtstat muss ja nur auf den Tag genau angegeben werden.
ich bin mir jedenfalls sicher, dass ich mein Geburtsdatum richtig eingegeben hab...
der IT-Boy hat es sich so erklärt:
- die rechnen YYYY-MM-DD Mitternacht mit GLib um in Sekunden seit 1970...
- dabei „vergessen“ die aber die Schaltsekunden mitzuzählen...
- dann verwenden die die UNIX Routine, um diese Zeitdifferenz wieder in Jahr/Monat/Tag umzurechnen...
- dabei rutschen die also auf 27 Sekunden vor Mitternacht am Vortag... YYYY-MM-(DD-1)
- und schon bin ich einen Tag älter, als mein Reisepass sagt...
- ein Buchungs Portal (check24) machte diese bescheuerte Umrechnung mehrfach hinter einander... da war ich dann ganze 2 Tage älter und es wurde immer schlimmer, je öfter ich mein Profil angeguckt hab, um die Telefonnummer zu ändern bspw...
. da war ich dann ganze 2 Tage älter und es wurde immer schlimmer, je öfter ich mein Profil angeguckt hab, um die Telefonnummer zu ändern bspw...
Das ist wirklich ärgerlich.
dann verwenden die die UNIX Routine, um diese Zeitdifferenz wieder in Jahr/Monat/Tag umzurechnen...
Aber dann müsste quasi jeder ältere Mensch mit einem falschen Datum in dem Dokument bei der Airline auftauchen. Das würde ja dann bemerkt werden.
die rechnen YYYY-MM-DD Mitternacht mit GLib um in Sekunden seit 1970...
gewagte Theorie. Ich würde da lieber keinerlei Umrechnung programmieren. Denn dann gibt es Probleme für Passagiere, die vor 1970 geboren wurden. Oder soll das jetzt mit negativen zahlen funktionieren?
Ich halte die Theorie vom IT.Menschen für sehr gewagt und denke, da könnte was anderes dahinter sein.
er hat ja unsere Arbeitsplatzrechner so umgestellt, dass sie die Schaltsekunden mitzählen... bei uns sind es seit Anfang 1970 immer 37 Sekunden mehr... kannst ja mal mit deinem Computer vergleichen...
> TZ=CET date;/bin/date +%s
2025-04-25T09:21:22CEST
1745565709
ja... die sollten einfach Jahr/Monat/Tag speichern...
check24 war es z. B.... mit dem phone geht aber alles perfekt...
Die Mathematik ist total einfach
Nicht wirklich, da die Schaltsekunden auf 'willkürlichen' Entscheidungen basieren und so mathematisch nicht beschreibbar sind. Von daher brauchst Du zwingend eine Datenbasis.
Leap Smear ist unabdingbar, wenn Du Monotonie zusichern willst - insofern ist das nicht ungewöhnlich sondern schlichweg Notwendigkeit.
und das Problem ist seit Jahrzehnten im Linux-Umfeld gelöst
Ne, POSIX (Epoch) sieht übrigens auch keine Schaltsekunden vor und leap-Zoneinfos gibt es noch nicht seit Jahrzehnten.
TAI und UTC sind sogar streng monoton... genau genommen... und beide verwenden SI Sekunden... anders als Google's Geschmiere... 😋
Von daher brauchst Du zwingend eine Datenbasis.
ja... einen Vektor mit den Zeitpunkten, die komisch sind... das läuft bei mir unter „Mathe“...
TAI ist auch monoton... und jede Sekunde ist ne SI Sekunde... Minuten sind immer 60 SI Sekunden...
UTC ist auch monoton, bloß dass einige Minuten 61 oder 59 Sekunden haben...
und das was Google macht, hat gar keinen Namen... das ist einfach nur übler Pfusch... wenn man die Zeit als Grundlage für iwas nimmt, dann ist das dann tagelang iwi komisch falsch... also für Flugsicherung oder Volumenstrom-Berechnung ist das alles nix...
So ein Aufriss für etwas, was alle paar Jahre mal vorkommt!?
GPS verwendet übrigens auch keine Schaltsekunden. Bzw. überträgt die aktuelle Differenz zwischen GPS-Zeit und UTC getrennt. Bloß falls du deswegen auch noch einen Rant starten willst.
unser IT-Boy hat mal ziemlich rumgelitten, dass er als Kind mal eine USB-Uhr gebastelt hat, die eines morgens total falsch ging.... das lag wohl an den Schaltsekunden, die oft auch von Linux nicht berücksichtigt werden (dazu muss man das speziell so hindrehen... und spezielle Zeit-Server verwenden, die nämlich die richtige Anzahl von Sekunden seit einem bestimmten Zeitpunkt ansagen...)...
es war wohl eine Sekunde falsch, aber sein Linux-Uhr-Treiber hat den Fehler in ppm umgerechnet... da sah es dramatischer aus... 😋 und er steht auf Drama... 😋
Sorry das ist nur scheinbar ein Problem.
Du brauchst einfach nur einen Timer der von Null bis Unendlich hochzählt.
So jetzt kommt aber der "Trick", "Lieber Computer sag mir bitte die Uhrzeit wenn ich in Berlin bin und es gerade Sommerzeit ist".
Dann wird aus dem internen Timer dann die aktuelle Uhrzeit.
in den internen Tabellen sind auch dann die möglichen Schaltsekungen, Sommerzeit und Zeitzonen gespeichert.
"Mathematik ist total einfach"
Nein, ist es nicht.
"und das Problem ist seit Jahrzehnten im Linux Umfeld gelöst"
Nein. Ist es nicht.
Schaltsekunden lassen sich nicht so einfach vorberechnen wie Schalttage, da die Rotation der Erde im Sekundenbereich unvorhersehbar schwankt.
Sie werden erst bei Bedarf eingefügt und an die UTC weitergeben.
Alle Zeitserver im Internet müssen sich dann selber mit UTC synchronisieren.
Man will ja sogar die Schaltsekunden abschaffen, weil der Nutzen im Verhältnis zum Aufwand und den damit verbundenen Problemen gering ist.
Nein, ist es nicht.
ist es wohl... s ist ne kleine Tabelle mit Minuten, die 61 statt 60 Sekunden haben...
und wohl ist das im Linux/Unix Umfeld gelöst... ich sitz doch selbst grad an sonem Ding:
> TZ=UTC date -d "2017-01-01 - 1 second"
2016-12-31T23:59:60UTC
> TZ=UTC date -d "2017-01-01 - 1 second" +%s
1483228826
> date -d@1483228825
2017-01-01T00:00:35TAI
> TZ=UTC date -d@1483228825
2016-12-31T23:59:59UTC
> date -d@1483228826
2017-01-01T00:00:36TAI
> TZ=UTC date -d@1483228826
2016-12-31T23:59:60UTC
> date -d@1483228827
2017-01-01T00:00:37TAI
> TZ=UTC date -d@1483228827
2017-01-01T00:00:00UTC
Schaltsekunden lassen sich nicht so einfach vorberechnen
die werden doch lange Zeit vorher angekündigt... da kann man einfach das Paket update-n...
Alle Zeitserver im Internet müssen sich dann selber mit UTC synchronisieren.
die kriegen auch son Update...
die werden doch lange Zeit vorher angekündigt... da kann man einfach das Paket update-n...
Das ist nicht sinn und zweck von Softwareupdates.
wenn du einen Service hast welcher Zugriff auf einen Service hat welcher Schaltsekunden mitnimmt dann ist es einfach.
Viele Pakete setzen das aber nicht vorraus bzw müssen auch ohne so einen Service auskommen.
Es ist zB für einen Library nicht gerade gut wenn die Internetzugang braucht und dann auf einem System verwendet wird welches keinen Internetzugang hat.
ja... unser IT-Boy meint, dass es reicht, wenn man diese UNIX Systemzeit verwendet (mit ner speziellen zoneinfo Datei und nem speziellen NTP server, der die vermurkste Internet Zeit um die Schaltsekunden ergänzt...)...
oder man benutzt seinen Temperatur kompensierten Spezial Präzisions Quarz, auf den er total stolz war... der muss in einer Art Kühlschrank im Heizungsraum stehen... massenhaft Styropor und an einer Seite hat der ein Loch für so ein elektrisches Kühl-Pack mit sonem fetten Kühlkörper... lol 😋