Hallo zusammen, ich hatte gerade den eigenartigen Effekt, dass ein Perl-Skript unter Windows sehr sehr viele Dateien neu verarbeitet hat, weil sich (angeblich) der Zeitstempel geändert hat. Genau weiss ichs nicht, aber ich vermute es hängt mit der Zeitumstellung auf Sommerzeit zusammen. ich hole mir den Zeitstempel mit stat($file)->mtime, wandle noch nach gmtime und speichere den Wert in einer Datenbank. Soweit ich weiss ist ja die mtime als "seconds until the epoch" definiert, und sollte sich mit der Sommerzeit ja nicht ändern, oder? oder doch?
Oder doch. Hatten wir auch schon mal. Google mal nach: get timestamp file dst https://www.google.de/search?q=get+timestamp+file+dst Gruß Roland
Michael R. schrieb: > Soweit ich weiss ist ja die mtime als "seconds until the epoch" > definiert, und sollte sich mit der Sommerzeit ja nicht ändern, oder? Oder. Windows hat die unangenehme Eigenschaft das die Änderung der Sommerzeit sich aufs Dateidatum auswirkt und so Dateien eine Stunde älter noder neuer sind. Hat was mit der Umrechnung auf die lokale Zeit zu tun. In Software wird das abgefangen indem Änderungen von genau einer Stunde ignoriert werden.
> In Software wird das abgefangen indem Änderungen von genau einer > Stunde ignoriert werden. Halte ich für Pfusch, weil wie der Teufel will, dann, in einem besonders obskuren Moment, für alle unerklärlich, eine einzelne, doch besonders wichtige Datei übersehen wird. Und wenn man jetzt noch bedenkt, dass Zeiten u.U. nur 2-Sekunden-genau gespeichert sind wird klar, dass es gar nicht so unwahrscheinlich ist, dass das Problem auch in der Praxis mal auftaucht.
Tilo R. schrieb: > Halte ich für Pfusch, weil wie der Teufel will, dann, in einem besonders > obskuren Moment, für alle unerklärlich, eine einzelne, doch besonders > wichtige Datei übersehen wird. Keine Frage, aber unter Windoof hat man halt keine andere Chance AFAIK. Der Timestamp ist IIRC bei NTFS in UTC und wird mit der lokalen Zeitumrechnung verarbeitet - und die ändert sich mit der Sommerzeit.
Jim M. schrieb: > Keine Frage, aber unter Windoof hat man halt keine andere Chance AFAIK. > Der Timestamp ist IIRC bei NTFS in UTC und wird mit der lokalen > Zeitumrechnung verarbeitet - und die ändert sich mit der Sommerzeit. Das meinen die doch aber bitte bitte bitte nicht ernst, oder? Nur damit ich das richtig verstehe: ich erstelle am 01.01.2018 um genau 12 Uhr mittag eine Datei. ich schau die gleich nachher an: Erstelldatum 2018-01-01 12:00:00 ich schau die letzte Woche an: Erstelldatum 2018-01-01 12:00:00 ich schau die heute an: Erstelldatum 2018-01-01 11:00:00 (oder 13:00) Das meinen die doch aber bitte bitte bitte nicht ernst, oder?
Michael R. schrieb: > Das meinen die doch aber bitte bitte bitte nicht ernst, oder? Willkommen in der wunderbar chaotischen Welt von Windows.
Jim M. schrieb: > Tilo R. schrieb: >> Halte ich für Pfusch, weil wie der Teufel will, dann, in einem besonders >> obskuren Moment, für alle unerklärlich, eine einzelne, doch besonders >> wichtige Datei übersehen wird. > > Keine Frage, aber unter Windoof hat man halt keine andere Chance AFAIK. > Der Timestamp ist IIRC bei NTFS in UTC und wird mit der lokalen > Zeitumrechnung verarbeitet - und die ändert sich mit der Sommerzeit. Der Timestamp ist immer UTC, egal ob Sommer- oder Winterzeit. Umrechnen muss man selbst. Keine Ahnung was Perl da unter der Haube macht. "A file time is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated Universal Time (UTC). The system records file times when applications create, access, and write to files. The NTFS file system stores time values in UTC format, so they are not affected by changes in time zone or daylight saving time. The FAT file system stores time values based on the local time of the computer." "You must take care when using file times if the user has set the system to automatically adjust for daylight saving time. To convert a file time to local time, use the FileTimeToLocalFileTime function. However, FileTimeToLocalFileTime uses the current settings for the time zone and daylight saving time. Therefore, if it is daylight saving time, it takes daylight saving time into account, even if the file time you are converting is in standard time." https://msdn.microsoft.com/de-de/library/windows/desktop/ms724290(v=vs.85).aspx (gilt im übrigen auch für andere Zeitfunktionen: GetLocalTime = lokale Zeit, GetSystemTime, ebenso wie unter div. Unices, Systemzeit in UTC)
Michael R. schrieb: > Das meinen die doch aber bitte bitte bitte nicht ernst, oder? Natürlich nicht. Der Computer kann immer noch Sommerzeit dazurechnen, ist ja nicht blöd. Ärgerlich ist das mit FAT, aber das wurde zu einer Zeit entwickelt, wo Computer üblicherweise keinen Internetzugang hatten und nicht um die halbe Welt getragen wurden. Da war die Zeitzone egal und es wurde einfach die lokale Zeit aus der RTC verwendet. Da gab es schlichtweg keine Info über die Zeitzone und die aktuelle UTC.
Arc N. schrieb: > To convert a file time to local time, use the FileTimeToLocalFileTime > function. However, FileTimeToLocalFileTime uses the current settings for > the time zone and daylight saving time. Therefore, if it is daylight > saving time, it takes daylight saving time into account, even if the > file time you are converting is in standard time." Und genau das ist Schwachsinn! (Aber MS verkauft es uns als Feature, bzw. behauptet "works as designed")
Michael R. schrieb: > Arc N. schrieb: >> To convert a file time to local time, use the FileTimeToLocalFileTime >> function. However, FileTimeToLocalFileTime uses the current settings for >> the time zone and daylight saving time. Therefore, if it is daylight >> saving time, it takes daylight saving time into account, even if the >> file time you are converting is in standard time." > > Und genau das ist Schwachsinn! (Aber MS verkauft es uns als Feature, > bzw. behauptet "works as designed") POSIX schreibt genau das vor: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html "The <sys/stat.h> header shall define the timespec structure as described in <time.h>. Times shall be given in seconds since the Epoch." umgewandelt wird mit localtime. Einziger Unterschied zu Windows: Unix zählt ab dem 1. Januar 1970, 00:00 UTC, Windows ab dem 1. Januar 1601, 00:00 UTC (in 100 ns Schritten)
Michael R. schrieb: > Und genau das ist Schwachsinn! Wie willst Du es anders machen? Nachdem ja jedes halbe Jahr daran gebohrt wird die Sommerzeit abzuschalten, muss man auch irgendwie die Möglichkeit haben eventuelle Änderungen zu implementieren.
Arc N. schrieb: > POSIX schreibt genau das vor: Richtig, hat aber mit dem Problem nichts zu tun! Karl schrieb: > Wie willst Du es anders machen? Richtig? So wie jedes andere, vernünftige OS? ich glaube aber, ihr beide habts das Problem nicht verstanden... ich versuchs nochmal zu erklären: die "File Modification Time" wird in UTC gespeichert, soweit so gut. Da kaum ein User in UTC denkt, wird sie in Lokalzeit umgerechnet. Soweit, so gut. Und nun kommt die Sommerzeit ins Spiel: unter Umständen muss eine zusätzliche Stunde mit berücksichtigt werden. nun ist die Frage, unter welchen Umständen: a) haben wir jetzt Sommerzeit? b) hatten wir zum Zeitpunkt der Modifikation Sommerzeit? Nun lohnt es sich durchaus darüber nachzudenken.... was ist richtig? Die Antwort zu finden überlasse ich dem geneigten Leser ;-) Nur so viel: Es gibt eine (und nur eine) richtige Antwort, und Windows nutzt die andere, falsche.
Michael R. schrieb: > die "File Modification Time" wird in UTC gespeichert, soweit so gut. Da > kaum ein User in UTC denkt, wird sie in Lokalzeit umgerechnet. Soweit, > so gut. Und nun kommt die Sommerzeit ins Spiel: unter Umständen muss > eine zusätzliche Stunde mit berücksichtigt werden. nun ist die Frage, > unter welchen Umständen: > > a) haben wir jetzt Sommerzeit? > b) hatten wir zum Zeitpunkt der Modifikation Sommerzeit? gute Frage ich stolpere auch gerade beim Proggen am 28/10/2018 wird um 3:00 Uhr die Uhrzeit auf 2:00 Uhr zurückgestellt Eine Dateizeit von 2:30 Uhr ist nun MESZ oder MEZ?
T.roll schrieb: > Willkommen in der wunderbar chaotischen Welt von Windows. Willkommen in der Welt, in der die gesetzliche Zeit nicht gleichmäßig abläuft. Aber solange die Politiker unseres Landes gefühlt ein halbes Jahr brauchen, um eine Regierung aufzustellen, können wir nicht erwarten, dass diese quatschige Dreherei an den gesetzlichen Uhren europaweit mal ein Ende hat. Auch unsere Bundesnetzagentur kriegt es auch nicht hin, eine vernünftige Netzfrequenz durchzusetzen, so dass netzgesteuerte Uhren in der letzten Zeit einen Stand von über 5 Minuten hatten. Erst nachdem es kräftig im Blätterwald gerauscht hat, wird es anscheinend langsam besser (nur noch 3m45s). Beitrag "Netzabweichung im Verbund" https://www.swissgrid.ch/swissgrid/de/home/experts/topics/frequency.html Michael R. schrieb: > Da kaum ein User in UTC denkt ... Man soll nicht unbedingt von sich auf andere schließen. Vermutlich bist du damit aber im selben Boot, wie der Autor des bemängelten Perl-Skripts. Manchmal hat es schon seine praktischen Gründe, UTC und die gesetzlich verunstaltete Zeitskala sauber auseinander zu halten. Unter Windows gibt es GetSystemTime für UTC, Konvertierung (RtlLocalTimeToSystemTime) und div. andere. Nützt aber alles nur, wenn man sie denn zu nutzen weiss. https://msdn.microsoft.com/en-us/library/windows/desktop/ms725473(v=vs.85).aspx
Joachim B. schrieb: > Michael R. schrieb: >> die "File Modification Time" wird in UTC gespeichert, soweit so gut. Da >> kaum ein User in UTC denkt, wird sie in Lokalzeit umgerechnet. Soweit, >> so gut. Und nun kommt die Sommerzeit ins Spiel: unter Umständen muss >> eine zusätzliche Stunde mit berücksichtigt werden. nun ist die Frage, >> unter welchen Umständen: >> >> a) haben wir jetzt Sommerzeit? >> b) hatten wir zum Zeitpunkt der Modifikation Sommerzeit? > > gute Frage ich stolpere auch gerade beim Proggen > > am 28/10/2018 wird um 3:00 Uhr die Uhrzeit auf 2:00 Uhr zurückgestellt > > Eine Dateizeit von 2:30 Uhr ist nun MESZ oder MEZ? Oder noch einen Schritt weitergedacht: Das System legt jede Stunde eine Datei an. Vor der Zeitumstellung um 2:30 wird eine Datei angelegt, und nach der Umstellung um 2:30 nach der neuen Zeit auch wieder. Wird für beide Dateien jetzt die gleiche Zeit angezeigt, oder spiegelt sich die Stunde Unterschied in der Anzeige wieder? Wenn ja, wie?
Beim Sprung vom 25.03 zeigt Win7 die vor 2 Uhr angelegte Datei 1:59, die nach 2 Uhr 3:00 korrekt an. Beim Sprung am 28.10. zeigt Win7 die vor 2 Uhr angelegte Datei als 1:59, die nach 2A als 2:00 bis 2:59 und die nach der Umstellung auf 2B als 2:00 korrekt an. Und: Die Dateien werden bei Sortierung nach Datum korrekt sortiert: Die in 2B erzeugte Datei wird nach den in 2A erzeugten angezeigt. Und das stimmt sowohl bei Sommerzeit als auch bei Winterzeit. Windows bekommt das anscheinend schon hin. Allerdings zeigt mein Filemanager (Freecommander) die im Sommer erstellten Dateien im Winter um eine Stunde falsch an, und die am 25.03. um 3:00:15 erstellte Datei für 2:00:15, obwohl es diese Zeit nicht geben kann. Ich hatte das Problem auch schon beim Programmieren: Bei Time() erwartet man eigentlich die aktuelle Zeit zurück. Läuft das Programm aber länger, und man wechselt die Zeitzone oder von Winter auf Sommerzeit, muss man vor Time() die LocalisationSettings neu einlesen, sonst gibt Time() die falsche Zeit zurück. Und wenn das ein Programm nicht macht, gibts halt Konfusion.
Joachim B. schrieb: > Eine Dateizeit von 2:30 Uhr ist nun MESZ oder MEZ? Wenn nicht gepfuscht wurde dann UTC (und von da aus eindeutig auf die zu diesem Zeitpunkt gültige Lokalzeit umrechenbar).
Jan H. schrieb: > Wenn nicht gepfuscht wurde dann UTC (und von da aus eindeutig auf die zu > diesem Zeitpunkt gültige Lokalzeit umrechenbar). Nur bei NTFS. Zeiten werden unter FAT32 als Lokalzeit gespeichert. Ich hab gerade mal die vorhin erstellten und aus Faulheit noch nicht gelöschten Testdateien auf einen USB-Stick mit FAT32 gezogen: Bei Sommerzeit alles wie auf NTFS. Beim Rückstellen des PC um eine Woche auf Winterzeit: Die mit Sommerzeit erstellten Dateien liegen jetzt eine Stunde in der Zukunft, die mit Winterzeit erstellte und bei Sommerzeit kopierte Datei liegt sogar zwei Stunden in der Zukunft. Dafür unterscheiden sich die in Stunde 2A und 2B bei Zeitumstellung erstellten Dateien jetzt um eine Stunde. Das hat mich einige Zeit genervt, als ich Backups von NTFS auf eine FAT32-Festplatte gemacht habe. Bis ich die Platte dann auf NTFS umformatiert habe.
Die Lösung dieser Probleme unter Windows ist ganz einfach: Als Zeitzone UTC konfigurieren! Dann läuft die Systemzeit streng monoton ohne Zeitsprünge und es gibt nur eineindeutige Timestamps. Wenn man dann auch alle Datenquellen wie Digitalkameras, die nur (Ex)FAT Medien abliefern, auf UTC stellt, spart man sich jegliche Zeitumstellungen. Auch im Urlaub bei Zeitzonenwechseln behält man so strikt lineare Timestamps. Und alle Synchronisationsprobleme mit NTFS Datenträgern unter Windows-Systemen ist man so ebenfalls los.
bluppdidupp schrieb: > https://www.codeproject.com/Articles/1144/Beating-the-Daylight-Savings-Time-bug-and-getting Danke! Und für Perl gibts auch eine Lösung: http://search.cpan.org/~shay/Win32-UTCFileTime-1.58/lib/Win32/UTCFileTime.pm "Gegen" Microsoft zu programmieren macht echt Spaß ;-)
Thorsten S. schrieb: > Die Lösung dieser Probleme unter Windows ist ganz einfach: > Als Zeitzone UTC konfigurieren! Oh Gott, ja. Es ist ja auch sooo ein großes Problem. Dafür nehm ich natürlich gern in Kauf, dass mein Kalender mich ein oder zwei Stunden zu spät an Termine erinnert, Termine falsch mit anderen Geräten synchronisiert werden, der Browser Webseiten nicht öffnet weil Zertifikate in der Zukunft liegen (hatte ich schon mit falsch gehender Systemzeit), Emails komische Zeitstempel haben oder ich meine Große eine Stunde zu spät vom Bus abhole, weil ich mich an der Computerzeit orientiert habe. Wenn schon UTC, dann verbindlich weltweit für alle. Würde sicher Flugpläne, Terminabsprachen usw. deutlich vereinfachen. Wird nie passieren, solange Länder stolz drauf sind Längen in Daumen und Füßen zu messen.
Karl schrieb: > Oh Gott, ja. Es ist ja auch sooo ein großes Problem. Verstellst du im Urlaub alle paar Tage deine Uhr in diverse Geräten, angefangen von der Kamera oder verbringst du den Urlaub lieber ortsfest in einem Liegestuhl, am liebsten noch am deutschen Strand?
Rolf M. schrieb: > Oder noch einen Schritt weitergedacht: Das System legt jede Stunde eine > Datei an. Vor der Zeitumstellung um 2:30 wird eine Datei angelegt, und > nach der Umstellung um 2:30 nach der neuen Zeit auch wieder. Wird für > beide Dateien jetzt die gleiche Zeit angezeigt, oder spiegelt sich die > Stunde Unterschied in der Anzeige wieder? Wenn ja, wie? Ja, es sollte die gleiche Zeit angezeigt werden, aber eine andere Zeitzone bzw. ein anderer Offset
1 | ls --full-time |
2 | 2018-03-25 02:30:00 +0100 File1.dat |
3 | 2018-03-25 02:30:00 +0200 File2.dat |
OffTopic: Eigentlich ist die Diskussion über Sommerzeit müßig: wenn ich aus dem Fenster schaue, schneit es hier schon wieder :-(
Karl schrieb: > Thorsten S. schrieb: >> Die Lösung dieser Probleme unter Windows ist ganz einfach: >> Als Zeitzone UTC konfigurieren! Ich finde, die einzig praktikable Lösung wäre die Abschaffung der Zeitumstellung. Das funktioniert sogar betriebssystemunabhängig. > Dafür nehm ich natürlich gern in Kauf, dass mein Kalender mich ein oder > zwei Stunden zu spät an Termine erinnert, Termine falsch mit anderen > Geräten synchronisiert werden, Die Termine liefern die Zeitzone selbstverständlich mit. Sonst gäbe es ja auch schon bei Terminen zwischen Leuten aus verschiedenen Zeitzonen komplettes Chaos. > der Browser Webseiten nicht öffnet weil Zertifikate in der Zukunft liegen > (hatte ich schon mit falsch gehender Systemzeit), Emails komische > Zeitstempel haben oder ich meine Große eine Stunde zu spät vom Bus > abhole, weil ich mich an der Computerzeit orientiert habe. Du meinst, nachdem du den Computer auf UTC umgestellt hast, vergisst du sofort, dass du das getan hast und lebst deshalb ab dann um eine Stunde versetzt? > Wenn schon UTC, dann verbindlich weltweit für alle. Würde sicher > Flugpläne, Terminabsprachen usw. deutlich vereinfachen. Swatch wollte mal eine eigene so genannte "Internetzeit" etablieren. Das war auch ohne Zeitzonen, und außerdem wurde gleich diese heute etwas merkwürdig anmutende 24/60-Teilung abgeschafft und der Tag einfach in 1000 Zeiteinheiten unterteilt. my2ct schrieb: > Karl schrieb: >> Oh Gott, ja. Es ist ja auch sooo ein großes Problem. > > Verstellst du im Urlaub alle paar Tage deine Uhr in diverse Geräten, > angefangen von der Kamera oder verbringst du den Urlaub lieber ortsfest > in einem Liegestuhl, am liebsten noch am deutschen Strand? In 80 Tagen um die Welt? Oder warum wechselst du im Urlaub alle paar Tage die Zeitzone? Nicht jeder hat Lust auf eine Kreuzfahrt mit dem Traumschiff. Michael R. schrieb: > Ja, es sollte die gleiche Zeit angezeigt werden, aber eine andere > Zeitzone bzw. ein anderer Offset > ls --full-time > 2018-03-25 02:30:00 +0100 File1.dat > 2018-03-25 02:30:00 +0200 File2.dat Hab ich aber bei graphischen Tools noch nie gesehen. Ich stell mir auch die Sortierung ggf. etwas irritierend vor, wenn z.B. erst eine Datei um 2:30 kommt, dann eine um 2:40 und dann eine um 2:20.
Rolf M. schrieb: >> Ja, es sollte die gleiche Zeit angezeigt werden, aber eine andere >> Zeitzone bzw. ein anderer Offset >> ls --full-time >> 2018-03-25 02:30:00 +0100 File1.dat >> 2018-03-25 02:30:00 +0200 File2.dat > > Hab ich aber bei graphischen Tools noch nie gesehen. Du hast recht, Windows bzw. dessen Explorer zeigt das nicht an, auch nicht in der Detailansicht. Mein Dolphin unter Linux schreibt aber die Zeitzone dazu (hier zB "CET" oder "CEST") > Ich stell mir auch > die Sortierung ggf. etwas irritierend vor, wenn z.B. erst eine Datei um > 2:30 kommt, dann eine um 2:40 und dann eine um 2:20. Naja, was willst du haben: irritierend aber richtig, oder weniger irritierend aber falsch?
Angehängte Dateien:
Michael R. schrieb: > Mein Dolphin unter Linux schreibt aber die Zeitzone dazu (hier zB "CET" > oder "CEST") Hast du das extra konfiguriert? Bei mir zeigt er das nicht an. Siehe Anhang. Ich hab aber auch keine Option gefunden, wo man das ändern könnte. Michael R. schrieb: >> Ich stell mir auch >> die Sortierung ggf. etwas irritierend vor, wenn z.B. erst eine Datei um >> 2:30 kommt, dann eine um 2:40 und dann eine um 2:20. > > Naja, was willst du haben: irritierend aber richtig, oder weniger > irritierend aber falsch? Was richtig und was falsch ist, ist Ansichtssache. Ist es richtig, zu behaupten, man sortiere nach dem, was angezeigt wird, aber stattdessen wird nach einer versteckten zweiten Zeit sortiert?
Rolf M. schrieb: > Michael R. schrieb: >> Mein Dolphin unter Linux schreibt aber die Zeitzone dazu (hier zB "CET" >> oder "CEST") > > Hast du das extra konfiguriert? Bei mir zeigt er das nicht an. Siehe > Anhang. Ich hab aber auch keine Option gefunden, wo man das ändern > könnte. rechte Maustaste - Details >> Naja, was willst du haben: irritierend aber richtig, oder weniger >> irritierend aber falsch? > > Was richtig und was falsch ist, ist Ansichtssache. Ist es richtig, zu > behaupten, man sortiere nach dem, was angezeigt wird, aber stattdessen > wird nach einer versteckten zweiten Zeit sortiert? Darüber ließe sich trefflich streiten ;-) Aber ich denke dieses Problem ist ein eher akademisches, weil es in der Praxis sehr selten auftreten wird. Das eigentliche Problem ist aber schon gröber, aber (zumindest in meinem Fall) mit dem speziellen Perl-Modul gelöst. Mich ärgert halt auch die MS-typische Herangehensweise: man baut etwas "broken by design", kommt drauf dass es Murks ist, bewirft das Problem mit noch mehr Murks, irgendwann kommt man drauf dass man aus dem Murks nicht mehr rauskommt, und behauptet "works as designed", bzw. (Zitat) but as Microsoft emphasized, this is how they want Windows to behave.
Michael R. schrieb: > rechte Maustaste - Details Details habe ich nicht. Meinst du Eigenschaften? Ja, dort ist das drin. Oben in deinem ls-Beispiel ging es aber um die Dateiliste, und ich dachte deshalb, du meintest diese auch bei Dolphin. Das Dateidatum von zwei Dateien im Vergleich zu sehen, ist halt auch etwas umständlich, wenn man immer erst den Dialog für jede Datei öffnen muss. >> Was richtig und was falsch ist, ist Ansichtssache. Ist es richtig, zu >> behaupten, man sortiere nach dem, was angezeigt wird, aber stattdessen >> wird nach einer versteckten zweiten Zeit sortiert? > > Darüber ließe sich trefflich streiten ;-) Aber ich denke dieses Problem > ist ein eher akademisches, weil es in der Praxis sehr selten auftreten > wird. Ja. Solange die gespeicherte Zeit es ermöglicht, kann das System es zumindest richtig behandeln. Für die Anzeige gibt es die perfekte Variante wohl nicht, aber damit kann man leben. > Mich ärgert halt auch die MS-typische Herangehensweise: man baut etwas > "broken by design", kommt drauf dass es Murks ist, bewirft das Problem > mit noch mehr Murks, irgendwann kommt man drauf dass man aus dem Murks > nicht mehr rauskommt, und behauptet "works as designed", > bzw. (Zitat) but as Microsoft emphasized, this is how they want Windows > to behave. Bei kaputten APIs von Microsoft habe ich als Entschuldigung in der Doku schon mehrfach "this behavior is by design" gesehen - nach dem Motto: Das ist kein Bug, sondern Absicht. Ich vermute, das steht immer dann dran, wenn dazu viele Bugreports eingegangen sind, aber man es nicht mehr ändern kann, weil es zu viele exitierende Programme beeinträchtigen würde.
Thorsten S. schrieb: > Die Lösung dieser Probleme unter Windows ist ganz einfach: > Als Zeitzone UTC konfigurieren! > > Dann läuft die Systemzeit streng monoton ohne Zeitsprünge und es gibt > nur eineindeutige Timestamps. Bis Schaltsekunden mit ins Spiel kommen.
Jemand schrieb: >> Dann läuft die Systemzeit streng monoton ohne Zeitsprünge und es gibt >> nur eineindeutige Timestamps. > > Bis Schaltsekunden mit ins Spiel kommen. ich sehe kein Problem mit Schaltsekunden...
Rolf M. schrieb: > In 80 Tagen um die Welt? Oder warum wechselst du im Urlaub alle paar > Tage die Zeitzone? Nein, nicht um die Welt, sondern auf 78° Nord per Schiff E-W. Eine Zeitzone sind da gerade mal 350km.
Jim M. schrieb: > In Software wird das abgefangen indem Änderungen von genau einer > Stunde ignoriert werden. Blödsinn. In Software wird das verhindert indem man für Zeitstempel eine Zeitzone verwendet in der die Zeit streng monoton steigend verläuft und nicht wild vor und zurück springt oder die selbe Zeit mehrmals am Tag vorkommen kann.
Ich habe einen digitalen Bilderrahmen mit WLAN-Verbindung (Kodak Pulse), der nach jeder Zeitumstellung für ein paar Tage keine Bilder empfangen kann. Er verbindet sich mit dem Server, lädt aber keine Bilder herunter. Ich habe wirklich keine Idee, was dort falsch programmiert ist. Manchmal treten Probleme mit der Zeitumstellung an unerwarteten Stellen auf.
dhcp lease time runtersetzen und das Problem hält sich dann in Grenzen.
Rolf M. schrieb: > In 80 Tagen um die Welt? Oder warum wechselst du im Urlaub alle paar > Tage die Zeitzone? Nicht jeder hat Lust auf eine Kreuzfahrt mit dem > Traumschiff. Es gibt auch Leute, die ab und an außerhalb des gut geheizten Büros arbeiten müssen. Rolf M. schrieb: > Die Termine liefern die Zeitzone selbstverständlich mit. Soweit die Theorie. In der Praxis kannst Du froh sein, wenn Du die .ics-Termine Deiner Anschlussflüge am gleichen Tag wiederfindest, wenn sich das Handy beim Zwischenstop ins Netz einbucht und auf die lokale Ortszeit umstellt. Ich dachte auch, sowas sollte technische kein Problem sein. Ist es anscheinend doch. Und nein, kein Windows-Phone.
Michael R. schrieb: > ich sehe kein Problem mit Schaltsekunden... Das gibt es aber theoretisch durchaus. In der Praxis derzeit zwar nicht, weil alle bekannten Schaltsekunden positiv waren und die Himmelsmechanik auf absehbare Zeit auch keine negativen Schaltsekunden erwarten läßt, aber wenn es doch mal mal dazu kommen sollte, dann knallt es in der Software aller Flachwichser, deren Horizont so eingeschränkt ist, wie deiner. Dazu gehört allerdings das gesamte WhoIsWho der gegenwärtig gebräuchlichen OS. Die für das jeweilige Zeitsystem Verantwortlichen haben zwar überall korrekt ihre Arbeit gemacht, um das Problem zu handeln, aber an unendlich vielen Stellen der OS, an denen das Zeitsystem nur noch genutzt wird, haben Leute wie du ihre Duftmarken gesetzt. Leute, die von einer monoton wachsenden Zeit ausgehen... Allerdings muß man wohl erwähnen: Wenn tatsächlich in absehbarer Zukunft ein himmelsmechanisches Event eintritt, welches geeignet wäre, eine negative Schaltsekunde notwendig zu machen, dann werden wir wohl im RL mit ganz anderen Problemen zu kämpfen haben als mit dem Zeitverlauf irgendwelcher Software-Uhren. Nur mit sehr viel Glück könnten wir ein solches Event wenigstens als Art überleben. Und wenn uns das überhaupt gelingt, dann wohl nur mit einem Rückfall in die Urgesellschaft. Technische Zivilisation adé, nix Computer...
Karl schrieb: > sich das Handy beim Zwischenstop ins Netz einbucht und auf die lokale > Ortszeit umstellt. Welch Glück, wenn mit Zertifikaten und falscher Zeit überhaupt noch was funktionierte! c-hater schrieb: > auf absehbare Zeit auch keine negativen Schaltsekunden erwarten läßt Viel "Spaß" mit Zeitrückstellung hatte ich vor Jahren unter Unix. Folge war, daß gar nix mehr ging und das Backup gesucht wurde.... Man sieht: Backup kann nützlich sein.
oszi40 schrieb: > Folge war, daß gar nix mehr ging und das Backup gesucht wurde Und habt ihr es wieder gefunden? Wo war es?
Bernd K. schrieb: > Und habt ihr es wieder gefunden? Wo war es? Klar, war frisch gemacht an einem sicheren Ort. Aus Erfahrung weiß ich heute, daß es besser ist, wenn man viele Backups hat, wenn man alte Stände braucht.
oszi40 schrieb: > Viel "Spaß" mit Zeitrückstellung hatte ich vor Jahren unter Unix. Folge > war, daß gar nix mehr ging und das Backup gesucht wurde. Was mich wundert: Man kann doch ein System nicht davon abhängig machen, dass es immer eine gültige Zeit hat. Was, wenn die Computerzeit vorläuft und dann vom Nutzer zurückgestellt wird? Oder per Inet-Sync? Was wenn die Batterie der RTC alle ist und der Rechner nur alle paar Wochen eingeschalten wird? Hatte ich letztens mit einem Schulrechner nach den Ferien. Und die "Firewall" der Schule läßt zwar Youtube problemlos durch, aber nicht den Zeitserver der PTB. Dann gehen die meisten Webseiten mit https nicht mehr, weil: Zertifikat liegt in der Zukunft. Ok, der Browser will halt nicht mehr, aber dass das ganze System unbenutzbar wird? Sowas muss benutzbar bleiben, und da darf weder eine Schaltsekunde noch eine Sommerzeitumstellung ein Problem sein.
c-hater schrieb: > In der Praxis derzeit zwar nicht, > weil alle bekannten Schaltsekunden positiv waren und die Himmelsmechanik > auf absehbare Zeit auch keine negativen Schaltsekunden erwarten läßt, > aber wenn es doch mal mal dazu kommen sollte, dann knallt es in der > Software aller Flachwichser, deren Horizont so eingeschränkt ist, wie > deiner. Was für Ereignisse erwartest du, die die Erddrehung gegenüber dem aktuellen Wert so stark beschleunigen könnten, dass negative Schaltsekunden erforderlich sein würden. Einen dicken Asteroideneinschlag vielleicht? Dann knallt es nicht nur in irgendwelcher Software, sondern noch ganz woanders.
So ganz schlecht kann es ja nicht funktionieren - jeder Raspberry Pi startet jedes Mal am 1.1.1970 um 0:00 Uhr, wenn keiner eine RTC dazugebastelt hat. Allerdings gibt es durchaus Nebeneffekte davon - z.B. wird der standardmäßig alle 180 Tage beim Start fällige fsck bei extN-Dateisystemen nicht ausgeführt, weil "last checked" in der Zukunft liegt. MfG, Arno
Auch make kommt dann durcheinander, weil die Erstellungszeit der Dateien in der Zukunft liegt. Man kann sich aber mit einem Trick behelfen, um die Zeit nicht rückwärts springen zu lassen und somit solche Effekte zu vermeiden: Beim Shutdown merkt man sich die Zeit und setzt die wieder beim nächsten Boot.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.