Sommer Zeit
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Auch Daylight Saving Time.
Ursprünglich zwecks Energieeinsparung eingeführt, die selbstverständlich nie eintrat. Im Gegenteil, die Sommerzeit verursacht letztlich zusätzliche erhebliche Kosten!
Darauf habe ich (hs) gewartet:
Bei eBay gab es jetzt schlimme Pannen, wegen der Umstellung Sommer -> Winterzeit. (*)
Die Zeitdauer von bereits laufenden Auktionen beinhaltete die Zeitumstellung. Das Auktionsende wurde falsch angezeigt. Dennoch waren die Auktionen korrekt eine Stunde vorher beendet und die Höchstbieter erhielten die entsprechenden Benachrichtigungen. Jedoch wurden die Auktionen gleichzeitig nochmals gestartet, für eine Stunde. Und neue Höchstbieter gab es dann, die die alten Höchstbieter oftmals überboten.
Die von der Region, also vom Ort abhängige Zeit war nie ein Problem. Jedoch die von der Zeit abhängige Zeit ist ein massives Problem! Besonders in der Programmierung. Das ist so ähnlich wie beim Lesen einer Bytefolge im Textmodus unter DOS/Win, wo die Zeilenende-Sequenz um ein Zeichen gekürzt wird, wodurch eine Inkonsistenz mit der wirklichen Dateiposition und Dateigröße entsteht.
Ich wünschte mir, man hätte diesen Mist nie eingeführt; es ist auch eine individuelle Anfangszeitregelung in den Firmen möglich. Bei nur einer Stunde kein Problem.
Ich warte auf die nächsten -schlimmeren- Probleme ...
(*) Heise online: "eBay stolpert in die Winterzeit", http://www.heise.de/newsticker/data/bo-26.10.03-002/
Eines der schlimmeren Probleme ist, dass Windows nach jedem Sommer/Normalzeitwechsel die Passwörter für die "Scheduled Tasks" vergisst und die aussagekräftige Meldung "Could not start" bei den Tasks anzeigt. Ich frage mich, was das eine mit dem anderen zu tun hat. -- anonym
- Das ist typisch, wenn eine Zeitreise unternommen wird. Die Zeit schreitet linear voran, solange nicht zwei Objekte mit Differenzgeschwindigkeit gleichzeitig betrachtet werden. Die Zeitumstellung jedoch läßt eine bereits absolvierte Stunde nochmals ablaufen. Es wird die Physik 'angelogen', und das rächt sich. Man hat es ja mit a) Zeitdauern und b) Zeitpunkten zu tun. Das gibt Probleme bei verteilten Bezügen. Ich wundere mich gar nicht, daß es diese Probleme bei "Scheduled Tasks" gibt. Es sind auch wahre Katastrophen denkbar, wenn irgendwas in der Stunde zwischen 2 Uhr und 2 Uhr 'schalten' soll. Ich habe bei Programmierungen schon festgestellt, daß ich in diesem scheinbaren Zeitraum Fehlerhaftigkeit pauschal zulassen mußte, weil es einfach keinen Ausweg gibt. -- hs
- Darum sollte man - als Programm - auch in UTC oder Ticks seit der Epoche denken; dort gibt es keine Zeitreisen. Alle Extrawürschte mit Zeitzonen, DST, Kalender und anderen Konfusionen sollten rein im Userinterface behandelt werden. Dort ist es dann auch notwendig und möglich zu unterscheiden ob 2003-10-26T02:30 noch Sommerzeit oder schon Winterzeit ist. -- DavidSchmitt
- Tja, es ist aber nicht so einfach, wenn sich die Domänenanforderungen an der lokalen Zeit orientieren. Mit der UTC allein kann man z.B. die Anforderung: "Zwischen 01:00 und 03:00 wird der Reaktor hochgefahren, in dieser Zeit bleiben die Schranken zu" oder "Der Ofen wird um 00:30 angemacht und um 04:00 ausgemacht" nicht realisieren. Es ist allerdings nicht nur ein Problem der Software, sondern auch der jeweiligen Domäne. Die Bahn löst es ganz elegant, indem sie die Fahrpläne wechselt. -- GregorRayman
- Niemand kann ein unterspezifiziertes Problem lösen. Soll der Reaktor alle 24h (um 01:00) hochgefahren werden? Oder soll er nur zwischen 01:00 und 03:00 gestartet werden? Oder wird er sowieso manuell gestartet und die Schranken sollen bloss mindestens eine Stunde vorher und nachher geschlossen sein? Braucht der Reaktor die vollen drei Stunden zum Hochfahren? In diesem Fall ist die Spezifikation sogar schon ganz fundamental falsch, da mit DST an einem Tag im Jahr nur zwei Stunden zwischen 1 und 3 sind! -- DavidSchmitt
- Genau! Alle diese Fragen muss man sich stellen, und unter Umständen muss die Steuerungssoftware alle solche Möglichkeiten berücksichtigen. (Reaktor um 01:00 für 3 Stunden laufen lassen; Schranken um 00:30 runterfahren und um 03:30 hochfahren (kann 2, 3, 4 Studen bedeuten). Für sich wiederholende Ereignisse reicht das einfache Eingeben der Zeit in UTC häufig nicht aus. -- GregorRayman
- Vorsicht, ich sprach nicht davon, dass Zeiten in UTC eingegeben werden sollten. Ich sprach davon, dass die (Steuerungs-)Software intern nur mit UTC rechnen soll und alle Umrechnungen von der lokalen Zeitzone von und zu UTC im Userinterface erfolgen sollen. Im Interface hat man nämlich noch die Möglichkeit alle obenaufgeführten Probleme vom USer lösen zu lassen, während man in der Steuerung nicht mehr mit Schaltstunden und ähnlichem zu kämpfen hat. Und ja, das bedeutet, dass das Userinterface möglicherweise komplexe Anweisungen an die Steuerungseinheit generieren muss. -- DavidSchmitt
- Sorry, wenn ich Dich missverstanden habe. Ich habe unter Userinterface mur die Oberfläche (Masken, Tatsen, usw.) verstanden, nicht das gesammte Programm, welches die Anweisungen auch speichert. Wenn die gesammte Komplexität in der benutzeroberfläche sein sollte, wäre es nicht besser, die Zeit aus der Steuerungseinheit ganz herauszunehmen und sich auf das einfach "jetzt" zu berschränken? Wie auch immer, das Problem der Sommer/Winterzeit ist dadurch nicht gelöst, dass die Komplexität in die Präsentationslogik verlagert wird. -- GregorRayman
- Ich gebe zu, ich habe es noch nicht ausprobiert, aber nachfragen, wenn Anweisungen über einen Zeitsprung hinweg gehen, klingt besser als dann mal den Reaktor nur 2 statt drei Stunden vorheizen. -- DavidSchmitt
- Wobei dieses konkrete Problem anscheinend ein bekanntes und umgehbares ist ( http://groups.google.de/groups?threadm=089a01c39e0a$06b91400$a601280a@phx.gbl). Als Argument gegen Sommerzeit taugt schlechte Software im übrigen nicht. -- vgl
Knifflig sind auch Termine: Die Uhrzeit des Termins ist an die lokale Zeit des Treffpunktes gebunden. Aber wo befindet sich der Teilnehmer etwa eine Stunde vor dem Treffen und nach welcher Zeit lebt er gerade? Hier kann man die Zeitangabe im Flugzeug als Idee aufgreifen: Es gibt zwei Zeiten, die am Start und die am Ziel. Termine bestehen aus der Zeit am Treffpunkt und evtl. davon abweichenden Zeiten ortsfester Computer, auf denen der Treffpunkt ausgehandelt wurde.
Ebenfalls nicht uninteressant: Wie machen es Videorecorder? Diese Dinger gelten ja als Paradebeispiel für ein von Laien zu programmierendes Gerät. Und die Schwierigkeiten fangen schon an, wenn eine Sendung um 0:00 Uhr anfängt. Die übliche Logik mit nur einer Datumsangabe funktioniert nur deshalb, weil man keine Marathonaufnahmen über mehrere Tage machen kann. Bei der Bahn hat man sich da mehr Gedanken machen müssen. Im Fahrplan gibt es eine Fülle von zeitbezogenen Spezialitäten wie Verkehrstageschlüssel und Nachtsprünge. Ich habe jüngst eine sogenannte Tagesfahrplanableitung programmieren dürfen - höchst interessant. -- SaschaDördelmann
- In Russland gibt (gab?) es die sogenannte Bahnzeit, die ausserhalb der Zeitzonen war und sich - wenn mich nicht alles täuscht - nach Moskauer Zeit richtete. Alle russischen Bahnhofsuhren zeigen die gleiche Uhrzeit an und alle Zeiten in den Fahrplänen sind Bahnzeit. Ein schönes Beispiel für eine homogene interne Zeitrepräsentation. -- DavidSchmitt
- Martin Fowler hatte einen interessanten Artikel über ganztägige Termine. Dabei ist das Problem, dass der Anfangs- und Endzietpunkt global nicht definiert sind. Wenn ich mir jetzt in den Kalender eintrage, dass ich z.B. den 4. Juli in New York verbringe, meine ich den 4. Juli als Tag, nicht die Zeitspanne 3.Juli 18:00-bis 4.Juli 18:00 New Yorker Zeit (was wenn ich mich nicht irre, der Zeit 4. Juli 00:00-24.00 CET entspricht) -- GregorRayman
Das Folgende muß man perfekt verstehen -und- der Programmierer muß es perfekt programmiert haben - sonst kann so Allerlei passieren.
Diese Option -s kenne ich nur von FreeBSD. Andere CRONs führen Kommandos bei der Zeitumstellung entweder doppelt oder garnicht aus (hs)!:
CRON FreeBSD: Available options:
-s Enable special handling of situations when the GMT offset of the
local timezone changes, such as the switches between the standard
time and daylight saving time.
The jobs run during the GMT offset changes time as intuitively
expected. If a job falls into a time interval that disappears
(for example, during the switch from standard time) to daylight
saving time or is duplicated (for example, during the reverse
switch), then it's handled in one of two ways:
The first case is for the jobs that run every at hour of a time
interval overlapping with the disappearing or duplicated inter-
val. In other words, if the job had run within one hour before
the GMT offset change (and cron was not restarted nor the
crontab(5) changed after that) or would run after the change at
the next hour. They work as always, skip the skipped time or run
in the added time as usual.
The second case is for the jobs that run less frequently. They
are executed exactly once, they are not skipped nor executed
twice (unless cron is restarted or the user's crontab(5) is
changed during such a time interval). If an interval disappears
due to the GMT offset change, such jobs are executed at the same
absolute point of time as they would be in the old time zone.
For example, if exactly one hour disappears, this point would be
during the next hour at the first minute that is specified for
them in crontab(5).
.
- Hübsche Beschreibung. Aber selbst das kann offensichtlich zu Problemen führen: falls ich jede Nacht um 2:45 und um 3:15 je einen Job ausführen lasse und dabei naiv annehme dass der Job von 2:45 tatsächlich als erster ausgeführt wird habe ich offensichtlich Pech gehabt...
KategorieZeit
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 24. Oktober 2012 9:10 (diff))