Lösung des Sommerzeit-Problems

[Gerby]

Die Angabe mit UTC ist tatsächlich unlogisch, aber sie funktioniert. Dummerweise habe ich bisher keine wirklich gute Doku zur TZ-Variable gefunden. Wie oben bereits angedeutet handelt es sich bei meiner Ausführung um eine Art Puzzle aus vielen Quellen.

Jetzt habe ich nochmal nachgelesen (Quellen A, B und C) und interpretiere das so:

• Die drei ersten Buchstaben sind einfach nur ein Name, der beliebig sein kann und keine Funktion hat.
• Die Zahl danach gibt den Unterschied zu UTC an und zwar von der lokalen Zeit aus gesehen. Bei uns in Deutschland ist das im Sommer halt -2 und im Winter -1.
• Theoretisch kann man auch noch eine Sommerzeitangabe machen. Aber das ist bei meiner Lösung mit der dynamischen Ermittlung des Zeitunterschieds nicht notwendig.

Folgendes steht also noch an:

1. Die Angabe von UTC ist in meinem Skript-Beispiel eher verwirrend, auch wenn es so funktioniert. Da könnte was hin wie LOC (für LOCal), CUR (für CURrent) oder vielleicht sogar WOU (Wsus Offline Update)?!
2. Wenn man die dynamische Ermittlung (mit VBScript und Aufruf in der DownloadUpdates.cmd) nicht nutzen möchte, kann man dauerhaft die TZ-Variable in Windows verankern:
   TZ = CET-1CEST (für mitteleuropäische Zeit/Sommerzeit)
3. Bei der dynamischen Ermittlung muss im VBScript noch die Zeitzonenberechnung verfeinert werden. Es gibt Zeitzonen, die nur um eine halbe Stunde versetzt sind. Dies wird z. B. durch -5:30 angegeben.

Ob das alles so funktionieren wird, kann ich noch nicht sagen, da ich es noch nicht getestet habe. In den nächsten Tagen habe ich auch wenig Zeit. Wenn ihr also schonmal ein wenig weiterprobieren möchtet...

[Gerby]

Und nun noch schnell eine neue Version der CurrentTimeZone:

Code: Select all

' *****************************************************
' * CurrentTimeZone.vbs V0.2.0 (by Gerby)             *
' * Determines the current time zone information      *
' * and returns the offset to UTC                     *
' *****************************************************

Set WshShell = WScript.CreateObject("WScript.Shell")
Registry_TimeBias =  "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\ActiveTimeBias"

TZ_Value = WshShell.RegRead(Registry_TimeBias)
TZ_Offset_Hours = TZ_Value \ 60  ' Integer result of division is used for hours
TZ_Offset_Minutes = abs(TZ_Value mod 60)  ' Remainder of division is used for minutes
if TZ_Offset_Minutes < 10 then
  TZ_Offset = "LOC" & TZ_Offset_Hours & ":0" & TZ_Offset_Minutes
else
  TZ_Offset = "LOC" & TZ_Offset_Hours & ":" & TZ_Offset_Minutes
end if
WScript.Echo TZ_Offset



Änderungen:

• Minuten bei der Zeitverschiebung werden berücksichtigt
• Anstatt "UTC" wird nun "LOC" als Bezeichner für die lokale Zeit verwendet.

[WSUSUpdateAdmin]

Moin!

Vielen Dank für Deine Bemühungen, Gerby, das sieht doch sehr vielversprechend aus!

Ich bin in den letzten Tagen leider nicht dazu gekommen, mich damit zu beschäftigen, entschuldige bitte, werde das aber so bald wie möglich nachholen.

Gruß
Torsten

[Alex]

Die Angabe mit UTC ist tatsächlich unlogisch, aber sie funktioniert. Dummerweise habe ich bisher keine wirklich gute Doku zur TZ-Variable gefunden. Wie oben bereits angedeutet handelt es sich bei meiner Ausführung um eine Art Puzzle aus vielen Quellen.

...

so:
TZ = CET-1CEST (für mitteleuropäische Zeit/Sommerzeit)
Ob das alles so funktionieren wird, kann ich noch nicht sagen, da ich es noch nicht getestet habe. In den nächsten Tagen habe ich auch wenig Zeit. Wenn ihr also schonmal ein wenig weiterprobieren möchtet...

Ich habe da noch eine gute Beschreibung von Michael Heydekamp in der Hilfe meines News/Mailclients (Crosspoint) gefunden, damit klappt hier auch die Sommer/Winterzeitumstellung.

Zitat:

Die TZ-Variable

Die TZ-Variable ist unter vielen Betriebssystemen zu
einem de-facto-Standard geworden und wird von einer
Reihe von Programmen unterstützt und ausgewertet
(u.a. PGP benötigt diese Variable, um mit der korrek-
ten Uhrzeit arbeiten zu können).

Das Format der Variablen hat viele unterschiedliche
Erscheinungsformen. Sie muß u.a. Angaben über die
Termine zur Umstellung der Sommer- bzw. Winterzeit
enthalten.

Mit den derzeit für Deutschland gültigen Werten
lautet der Befehl wie folgt:

TZ=CET-1CEST,3,-1,0,7200,10,-1,0,10800,3600

Die einzelnen Felder der Variablen haben dabei
folgende Bedeutung:

CET: Bezeichnung der Zeitzone (Winterzeit, hier
"Central European Time"). Es gibt eine Fülle
unterschiedlicher und mehr oder weniger
offizieller Bezeichnungen - eine Übersicht
finden Sie unter "Zeitzonen".
-1: Eine Stunde östlich von UTC (Universal
Time Coordinated, in der Praxis identisch
mit "Greenwich Mean Time", GMT). Zeitzonen
östlich des Null-Meridians werden mit nega-
tiven Zahlen dargestellt, Zeitzonen westlich
davon mit positiven Zahlen.
CEST: Bezeichnung der Zeitzone (Sommerzeit, hier
"Central European Summer Time"). Siehe auch
"Zeitzonen".
3: Monat, in dem auf Sommerzeit umgestellt wird
(dritter Monat = März).
-1: Woche, in der auf Sommerzeit umgestellt wird
(letzte Woche). Die Wochen werden vom Beginn
des Monats ausgehend mit positiven Zahlen
dargestellt, vom Ende des Monats ausgehend
mit negativen Zahlen.
0: Tag, an dem auf Sommerzeit umgestellt wird
(0=Sonntag bis 6=Samstag).
7200: Zeitspanne in Sekunden nach Tagesbeginn,
nach der auf Sommerzeit umgestellt wird
(7200 Sekunden = 02:00 Uhr).
10: Monat, in dem auf Winterzeit umgestellt wird
(zehnter Monat = Oktober).
-1: Woche, in der auf Winterzeit umgestellt wird
(letzte Woche).
0: Tag, an dem auf Winterzeit umgestellt wird
(0=Sonntag bis 6=Samstag).
10800: Zeitspanne in Sekunden nach Tagesbeginn,
nach der auf Winterzeit umgestellt wird
(10800 Sekunden = 03:00 Uhr).
3600: Differenz zwischen Winter- und Sommerzeit
in Sekunden (3600 Sekunden = 1 Stunde).

[Gerby]

Ich bin in den letzten Tagen leider nicht dazu gekommen, mich damit zu beschäftigen, entschuldige bitte, werde das aber so bald wie möglich nachholen.

Hallo Torsten!

Überhaupt kein Problem! Das Ganze ist ja sowieso noch am Reifen.

Im VBSkript habe ich übrigens absichtlich noch nicht solche Zusätze "Option Explicit" oder "Dim" eingebaut, um es in der Entwicklungsphase einigermaßen übersichtlich zu halten. Ich denke mal, dass Du den Aufruf in DownloadUpdates.cmd auch noch absichern würdest (falls sich das Ganze als anwendbar herausstellt und Du es implementierst).

@all: Kann mir noch jemand eine Rückmeldung zum Thema FAT geben? Ich schätze mal, dass es bei Downloads auf FAT und anschließender Zeitumstellung Mehrfachdownloads gibt, unabhängig davon, ob die Zeitzonenanpassung implementiert ist oder nicht. Das leite ich (in der Theorie) davon ab, dass die Dateien bei FAT jeweils mit einem festen Zeitstempel abgelegt werden, dessen Zeitangabe sich auch bei einer Zeitumstellung im System nicht ändert.

Gruß
Mark

[scharl]

Danke erst einmal an Gerby für seine Bemühungen, das Sommerzeit-Problem zu umgehen. Ich denke, dass der Workaround mit der TZ-Umgebungsvariable wohl für die nächste Zeit die praktikabelste Lösung sein wird.

Im c't Offline Update Ticket wurde es schon einmal erwähnt, aber ich will hier nochmal etwas ausführlicher über die Hintergründe schreiben, warum es überhaupt zu erneuten Donwloads im Zusammenhang mit der Sommerzeit kommt.

Wget überprüft durch Vergleich der vom Server gemeldeten Zeit und des Zeit der lokalen Datei, ob ein Download nötig ist. Dazu verwendet es die C-Runtime-Funktion stat() zum Einlesen des Änderungsdatums und gegebenenfalls nach Beendigung des Download utime() zum Setzen des Änderungsdatums auf den vom Server gemeldeten Wert.
Und hier fängt das Problem an: Die meisten wget-Versionen für Windows, inklusive der bei Offline Update mitgelieferten, verwenden die Microsoft-C-Runtime und die hat einen Bug: Wie in KB190315 aufgeführt, verwenden die C-Runtime-Funktionen falsche Uhrzeiten, wenn Windows so eingestellt ist, dass automatisch zwischen Sommer- und Winterzeit umgestellt wird.

Um dieses Problem in wget zu umgehen, gibt es zwei Möglichkeiten:
1. Man verwendet eine C-Runtime, die nicht von Microsoft stammt.
Das wird z. B. bei Cygwin gemacht, weshalb das dort mitgelieferte wget immer die richtigen Zeiten verwendet.
2. Man ändert den Sourcecode von wget.
Das Problem mit den falschen Zeiten gibt es ja nicht nur bei wget, sondern auch bei anderen Programmen, die die betroffenen Funktionen aus der Microsoft-C-Runtime benutzen. Hier ist recht ausführlich beschrieben, warum es überhaupt zu dem Zeit-Problem kommt und wie es umgangen werden kann. Dazu verwendet man statt der C-Runtime- Win32-API-Funktionen: utime() ersetzt man durch SetFileTime() und bei stat() holt man sich die korrekten Zeiten mit GetFileInformationByHandle().

Eine wget-Version, die sich in Bezug auf Sommerzeit richtig verhält, werden wir so schnell aber wohl nicht bekommen. Denn selbst wenn der Sourcecode so geändert wird, dass die Win32-API-Funktionen genutzt werden, gibt es offensichtlich immer noch das Problem, dass sich wget seit Version 1.12 nicht mehr mit Visual Studio übersetzen lässt. Das ist zwar schon seit mindestens eineinhalb Jahren bekannt, wird aber anscheinend derzeit nicht bearbeitet.

Die Verwendung einer wget.exe, die nicht die Microsoft-C-Runtime benutzt, wäre zwar möglich. Aber das Cygwin-wget benötigt einige zusätzliche DLLs und andere Implementierung ohne die Microsoft-C-Runtime sind mir nicht bekannt.


Zur Nutzung der TZ-Umgebungsvariable hätte ich auch noch ein paar Anmerkungen:
Diese Umgebunsvariable wird genau genommen nicht von wget selbst berücksichtigt, sondern es sind die Aufrufe der Microsoft-C-Runtime-Funktionen, wo TZ beachtet wird. Nur wenn die Umgebungsvariable nicht gesetzt ist, werden die Zeitzoneneinstellungen aus der Registry verwendet.

Weil hier auch der Vorschlag kam, die TZ-Umgebungsvaribale dauerhaft zu setzen. Man muss sich dann natürlich im Klaren sein, dass nicht nur wget, sondern eventuell auch andere Programme, die die Microsoft-C-Runtime verwenden, Zeitumrechnungen anders machen als wenn die Variable nicht gesetzt ist.

[Gerby]

Hallo Scharl!

Willkommen im Forum und einen herzlichen Dank für die ausführliche und trotzdem übersichtliche Erklärung der Hintergründe. *thumb up*

[WSUSUpdateAdmin]

Moin!

Ich hab' das jetzt mal eingebaut ( http://trac.wsusoffline.net/browser/trunk (r237)), und bei mir funktioniert's!
Was ich (noch) nicht getestet habe, ist ein Benutzer ohne Admin-Rechte.
Für "Puristen, Paranoide und geprannte Kinder" gibt's den Switch "/skiptz".

Vielen Dank nochmal & viele Grüße
Torsten

[harry]

Vielleicht noch eine kleine Änderung für "krumme" Zeitzonen:

Code: Select all

if "%SKIP_TZ%" NEQ "1" (
  for /F "tokens=3" %%i in ('%SystemRoot%\system32\reg.exe QUERY HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v ActiveTimeBias /t REG_DWORD ^| %SystemRoot%\system32\find.exe /I "ActiveTimeBias"') do set /A TZ="%%i/60"
  set TZ=LOC!TZ!
  echo %DATE% %TIME% - Info: Set time zone to !TZ! >>%DOWNLOAD_LOGFILE%
)

ändern in

Code: Select all

if "%SKIP_TZ%" NEQ "1" ( 
  for /F "tokens=3" %%i in ('%SystemRoot%\system32\reg.exe QUERY HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v ActiveTimeBias /t REG_DWORD ^| %SystemRoot%\system32\find.exe /I "ActiveTimeBias"') do (
  set /A TZ="%%i/60" , TZ1="%%i-(TZ*60)"
  set TZ1=0!TZ1!
  )
  set TZ=LOC!TZ!:!TZ1:~-2! 
  echo %DATE% %TIME% - Info: Set time zone to !TZ! >>%DOWNLOAD_LOGFILE%
)

[WSUSUpdateAdmin]

Ah ja, richtig, der "Chavez-Schalter" , den hatte ich vergessen.

Danke, harry, super Code, baue ich ein.

Gruß & gute N8
Torsten