# Ermitteln ob Zeitumstellung war



## Christoph74 (6. Nov 2018)

Hallo,

gibt es irgendeine Möglichkeit herauszufinden, wann (Tag) die Zeitumstellung (Sommer/Winterzeit) stattgefunden hat?
(und ggf. in Zukunft statt finden wird)

Danke und Grüße
Christoph


----------



## MoxxiManagarm (6. Nov 2018)

Ich meine es ist immer der letzte Sonntag im März und der letzte Sonntag im Oktober?! Das dürftest du doch mit Java herausfinden können.


----------



## max40 (6. Nov 2018)

seit 1980 so wie MoxxiManagarm geschrieben hat, davor kann man hier nachlesen: https://de.wikipedia.org/wiki/Liste_der_Sommerzeiten#Deutschland
Und in Zukunft kann sich das ändern.


----------



## Christoph74 (6. Nov 2018)

"Und in Zukunft kann sich das ändern."
-> und genau, das ist mein Problem  -> darf hier (auch in Zukunft) diesbezüglich kein Fehler im Programm drin sein... :-(


----------



## Xyz1 (6. Nov 2018)

Christoph74 hat gesagt.:


> gibt es irgendeine Möglichkeit herauszufinden


Nur als Wahrsager kannst Du das herausfinden.


----------



## Christoph74 (6. Nov 2018)

gut, dann schmeiss ich hier jetzt alles hin und werde Wahrsager... ;-)

Trotzdem Danke Jungs


----------



## Xyz1 (6. Nov 2018)

....Dann kannst Du in die Zukunft und Vergangenheit blicken und hast eine Glaskugel.


----------



## Christoph74 (6. Nov 2018)

wobei ich ja eigentlich "nur" wissen müsste, ob eine Zeitumstellung WAR...


----------



## mrBrown (6. Nov 2018)

Wenn das längere Zeit laufen soll, wird das nicht ohne Update oder externen Service klappen.


----------



## Xyz1 (6. Nov 2018)

Was soll dieser Schwachsinn mit Update un Service? Denke nicht dass er einen IC im Weltraum laufen lässt....
Wenn es NUR um die Vergangenheit geht brauch er lediglich ne Liste mit Zeitumstellungen....


----------



## mrBrown (6. Nov 2018)

DerWissende hat gesagt.:


> Was soll dieser Schwachsinn mit Update un Service? Denke nicht dass er einen IC im Weltraum laufen lässt....
> Wenn es NUR um die Vergangenheit geht brauch er lediglich ne Liste mit Zeitumstellungen....



Angenommen:
 * Er schreibt das Programm jetzt mit der jetzt bekannten Liste von Zeitumstellungen.
 * EU beschließt, ab 2019 gibt es nur noch Sommerzeit.
 * Das Programm läuft 2020 noch.

Wie gut funktioniert es dann wohl, wenn man es bis dahin nicht updatet oder nen externen Service nutzt?


----------



## Xyz1 (6. Nov 2018)

Das ändert doch nüschts daran das EU 2021 beschließen könnte die Zeitumstellung wieder einzuführen und damit das Programm nicht für die Zukunft richtig sein könnte, also nicht wiederspruchsfrei zu "keine Fehler" is.


----------



## mrBrown (6. Nov 2018)

Hach, du bist einfach der beste, wenn es darum geht, klare und deutliche Antworten zu geben <3


----------



## Xyz1 (6. Nov 2018)

Wusst ichs doch


----------



## mihe7 (6. Nov 2018)

Stellt Euch nicht so an: Webservice-Client...


----------



## Xyz1 (6. Nov 2018)

Entschuldigung mrBrown ich wollte nicht unfreundlich sein. Wir beide können recht haben


----------



## Christoph74 (7. Nov 2018)

Webservice scheidet leider aus -> die Software läuft in nem autarken Netz.
Hatte (ein KLEINES Fünkchen Hoffnung), dass vielleicht das System irgendwo speichert (ups...da war ne Zeitumstellung) -> weil die Systemzeit wird ja beim Zeitabgleich um ne Stunde zurückgestellt.

Danke an alle und seid nett zueinander... ;-)


----------



## mihe7 (7. Nov 2018)

Christoph74 hat gesagt.:


> Webservice scheidet leider aus


LOL - das war auch nur auf @mrBrown und @DerWissende gemünzt.



Christoph74 hat gesagt.:


> Hatte (ein KLEINES Fünkchen Hoffnung), dass vielleicht das System irgendwo speichert (ups...da war ne Zeitumstellung) -> weil die Systemzeit wird ja beim Zeitabgleich um ne Stunde zurückgestellt.


Das kannst Du natürlich machen. Einfach jede Stunde einen Zeitabgleich durchführen. Ist die Differenz größer als x Minuten (EDIT: bzw. kleiner als x' Minuten), hast Du eine Zeitumstellung am System erkannt. Die muss natürlich nichts mit Winter- oder Sommerzeit zu tun haben.


----------



## max40 (7. Nov 2018)

Hatte mir mal ebend TimeZone geholt und gesehen das dort ein haufen Daten unter transitions vorhanden sind.
mit google und java time transitions bin ich dann auf folgende Seite gelandet: https://stackoverflow.com/questions/41723123/java-timezone-what-transitions-mean


```
import java.lang.reflect.Field;
import java.time.Instant;
import java.util.TimeZone;

public class Time {

    public static void main(String[] args) {

       TimeZone tz = TimeZone.getTimeZone("CET");

        Field f = null;
        try {
            f = tz.getClass().getDeclaredField("transitions");
            f.setAccessible(true);
            long[] transitions = (long[]) f.get(tz);
            f = tz.getClass().getDeclaredField("offsets");
            f.setAccessible(true);
            int[] offsets = (int[]) f.get(tz);

            for ( long transition : transitions ) {
                Instant transitionInstant = Instant.ofEpochMilli(transition >> 12);
                int offset = offsets[(int)transition & 0xF];
                System.out.println( transitionInstant + " : " + offset);
            }
        } catch (NoSuchFieldException | SecurityException | IllegalArgumentException | IllegalAccessException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
       
    }

}
```

mit folgenden Output:

```
1900-01-01T00:00:00Z : 3600000
1916-04-30T22:00:00Z : 7200000
1916-09-30T23:00:00Z : 3600000
1917-04-16T01:00:00Z : 7200000
1917-09-17T01:00:00Z : 3600000
1918-04-15T01:00:00Z : 7200000
1918-09-16T01:00:00Z : 3600000
1940-04-01T01:00:00Z : 7200000
1942-11-02T01:00:00Z : 3600000
1943-03-29T01:00:00Z : 7200000
1943-10-04T01:00:00Z : 3600000
1944-04-03T01:00:00Z : 7200000
1944-10-02T01:00:00Z : 3600000
1945-04-02T01:00:00Z : 7200000
1945-09-16T01:00:00Z : 3600000
1977-04-03T01:00:00Z : 7200000
1977-09-25T01:00:00Z : 3600000
1978-04-02T01:00:00Z : 7200000
1978-10-01T01:00:00Z : 3600000
1979-04-01T01:00:00Z : 7200000
1979-09-30T01:00:00Z : 3600000
1980-04-06T01:00:00Z : 7200000
1980-09-28T01:00:00Z : 3600000
1981-03-29T01:00:00Z : 7200000
1981-09-27T01:00:00Z : 3600000
1982-03-28T01:00:00Z : 7200000
1982-09-26T01:00:00Z : 3600000
1983-03-27T01:00:00Z : 7200000
1983-09-25T01:00:00Z : 3600000
1984-03-25T01:00:00Z : 7200000
1984-09-30T01:00:00Z : 3600000
1985-03-31T01:00:00Z : 7200000
1985-09-29T01:00:00Z : 3600000
1986-03-30T01:00:00Z : 7200000
1986-09-28T01:00:00Z : 3600000
1987-03-29T01:00:00Z : 7200000
1987-09-27T01:00:00Z : 3600000
1988-03-27T01:00:00Z : 7200000
1988-09-25T01:00:00Z : 3600000
1989-03-26T01:00:00Z : 7200000
1989-09-24T01:00:00Z : 3600000
1990-03-25T01:00:00Z : 7200000
1990-09-30T01:00:00Z : 3600000
1991-03-31T01:00:00Z : 7200000
1991-09-29T01:00:00Z : 3600000
1992-03-29T01:00:00Z : 7200000
1992-09-27T01:00:00Z : 3600000
1993-03-28T01:00:00Z : 7200000
1993-09-26T01:00:00Z : 3600000
1994-03-27T01:00:00Z : 7200000
1994-09-25T01:00:00Z : 3600000
1995-03-26T01:00:00Z : 7200000
1995-09-24T01:00:00Z : 3600000
1996-03-31T01:00:00Z : 7200000
1996-10-27T01:00:00Z : 3600000
1997-03-30T01:00:00Z : 7200000
1997-10-26T01:00:00Z : 3600000
1998-03-29T01:00:00Z : 7200000
1998-10-25T01:00:00Z : 3600000
1999-03-28T01:00:00Z : 7200000
1999-10-31T01:00:00Z : 3600000
2000-03-26T01:00:00Z : 7200000
2000-10-29T01:00:00Z : 3600000
2001-03-25T01:00:00Z : 7200000
2001-10-28T01:00:00Z : 3600000
2002-03-31T01:00:00Z : 7200000
2002-10-27T01:00:00Z : 3600000
2003-03-30T01:00:00Z : 7200000
2003-10-26T01:00:00Z : 3600000
2004-03-28T01:00:00Z : 7200000
2004-10-31T01:00:00Z : 3600000
2005-03-27T01:00:00Z : 7200000
2005-10-30T01:00:00Z : 3600000
2006-03-26T01:00:00Z : 7200000
2006-10-29T01:00:00Z : 3600000
2007-03-25T01:00:00Z : 7200000
2007-10-28T01:00:00Z : 3600000
2008-03-30T01:00:00Z : 7200000
2008-10-26T01:00:00Z : 3600000
2009-03-29T01:00:00Z : 7200000
2009-10-25T01:00:00Z : 3600000
2010-03-28T01:00:00Z : 7200000
2010-10-31T01:00:00Z : 3600000
2011-03-27T01:00:00Z : 7200000
2011-10-30T01:00:00Z : 3600000
2012-03-25T01:00:00Z : 7200000
2012-10-28T01:00:00Z : 3600000
2013-03-31T01:00:00Z : 7200000
2013-10-27T01:00:00Z : 3600000
2014-03-30T01:00:00Z : 7200000
2014-10-26T01:00:00Z : 3600000
2015-03-29T01:00:00Z : 7200000
2015-10-25T01:00:00Z : 3600000
2016-03-27T01:00:00Z : 7200000
2016-10-30T01:00:00Z : 3600000
2017-03-26T01:00:00Z : 7200000
2017-10-29T01:00:00Z : 3600000
2018-03-25T01:00:00Z : 7200000
2018-10-28T01:00:00Z : 3600000
2019-03-31T01:00:00Z : 7200000
2019-10-27T01:00:00Z : 3600000
2020-03-29T01:00:00Z : 7200000
2020-10-25T01:00:00Z : 3600000
2021-03-28T01:00:00Z : 7200000
2021-10-31T01:00:00Z : 3600000
2022-03-27T01:00:00Z : 7200000
2022-10-30T01:00:00Z : 3600000
2023-03-26T01:00:00Z : 7200000
2023-10-29T01:00:00Z : 3600000
2024-03-31T01:00:00Z : 7200000
2024-10-27T01:00:00Z : 3600000
2025-03-30T01:00:00Z : 7200000
2025-10-26T01:00:00Z : 3600000
2026-03-29T01:00:00Z : 7200000
2026-10-25T01:00:00Z : 3600000
2027-03-28T01:00:00Z : 7200000
2027-10-31T01:00:00Z : 3600000
2028-03-26T01:00:00Z : 7200000
2028-10-29T01:00:00Z : 3600000
2029-03-25T01:00:00Z : 7200000
2029-10-28T01:00:00Z : 3600000
2030-03-31T01:00:00Z : 7200000
2030-10-27T01:00:00Z : 3600000
2031-03-30T01:00:00Z : 7200000
2031-10-26T01:00:00Z : 3600000
2032-03-28T01:00:00Z : 7200000
2032-10-31T01:00:00Z : 3600000
2033-03-27T01:00:00Z : 7200000
2033-10-30T01:00:00Z : 3600000
2034-03-26T01:00:00Z : 7200000
2034-10-29T01:00:00Z : 3600000
2035-03-25T01:00:00Z : 7200000
2035-10-28T01:00:00Z : 3600000
2036-03-30T01:00:00Z : 7200000
2036-10-26T01:00:00Z : 3600000
2037-03-29T01:00:00Z : 7200000
2037-10-25T01:00:00Z : 3600000
```


----------



## Thallius (7. Nov 2018)

Erstelle einen service der jede Stunde einen Eintrag der aktuellen Uhrzeit in eine Datei schreibt. Anhand dieser Datei kannst du dann jederzeit feststellen wann die Zeitumstellungen waren. (Wenn deine SW mit einer DB arbeitet kannst du das natürlich auch gleich in eine Tabelle der DB schreiben)

DAs sind dann ca. 9000 Einträge pro Jahr. Das sollte also auch in 100 Jahren noch akzeptabel schnell sein und bis dahin bist du eh tot und es kann dir egal sein 

Gruß

Claus


----------



## max40 (7. Nov 2018)

@Thallius kann man zwar auch machen, aber irgendwo sind ja die Daten hinterlegt, wann eine Zeitumstellung ist.

Warum soll er sich 9000 Sätze merken pro Jahr? es reicht doch wenn er sich die Zeiten merkt wo er die abweichungen feststellt. Damit hat er 2 Datensätze und gut ist. Und jedesmal wenn er eine neuere Java-Version hat, dann muss er das nochmal machen, da ggf. die neue Version Infos darüber hat, wie die Zeitumstellung ist falls sich was ändert.


----------



## Christoph74 (7. Nov 2018)

Ja, das mit dem Zwischenspeichern der Zeiten war dann jetzt auch mein letzter Gedanke (bin aber noch nicht Tot! ;-) ) => werde das wohl so umsetzen...

und in spätestens 24 Jahren bin ich in Rente -> danach kanns mir eigentlich schon... ;-).


----------



## Meniskusschaden (7. Nov 2018)

max40 hat gesagt.:


> @Thallius kann man zwar auch machen, aber irgendwo sind ja die Daten hinterlegt, wann eine Zeitumstellung ist.


Ich habe folgende Aussage so verstanden, dass er nicht ausserhalb seines Netzes nachsehen kann:


Christoph74 hat gesagt.:


> Webservice scheidet leider aus -> die Software läuft in nem autarken Netz.


Das "irgendwo nachsehen" kommt also wohl nicht in Betracht.


max40 hat gesagt.:


> Warum soll er sich 9000 Sätze merken pro Jahr?


Der Vorschlag von @Thallius lässt sich ja leicht so abwandeln, dass man alte Datensätze löscht oder gar nicht erst speichert. Eigentlich genügt es ja, mit dem vorigen Datensatz zu vergleichen, also sollte es ausreichen, die neue Messung mit der vorigen Messung zu vergleichen und dann die vorige Messung mit der neuen Messung zu überschreiben. Wenn sich die Differenz zwischen UTC und lokaler Zeit signifikant verändert hat, gab es eine Zeitumstellung. Man kommt also mit einem Datensatz aus.


----------



## mihe7 (7. Nov 2018)

Meniskusschaden hat gesagt.:


> Eigentlich genügt es ja, mit dem vorigen Datensatz zu vergleichen, also sollte es ausreichen, die neue Messung mit der vorigen Messung zu vergleichen und dann die vorige Messung mit der neuen Messung zu überschreiben. Wenn sich die Differenz zwischen UTC und lokaler Zeit signifikant verändert hat, gab es eine Zeitumstellung.



Ihr dreht Euch im Kreis:


mihe7 hat gesagt.:


> Einfach jede Stunde einen Zeitabgleich durchführen. Ist die Differenz größer als x Minuten (EDIT: bzw. kleiner als x' Minuten), hast Du eine Zeitumstellung am System erkannt. Die muss natürlich nichts mit Winter- oder Sommerzeit zu tun haben.


----------



## max40 (7. Nov 2018)

Meniskusschaden hat gesagt.:


> Ich habe folgende Aussage so verstanden, dass er nicht ausserhalb seines Netzes nachsehen kann:


das muss er auch nicht, weil die ganzen Informationen in java hinterlegt sein müssen. Woher soll java sonst wissen, das am Tag x eine Zeitumstellung ist.


----------



## mrBrown (7. Nov 2018)

Da wird man sich auch weiter im Kreis drehen 

Entweder es ist vollkommen autark, dann bricht es bei der nächsten Änderung (die ja aktuell nicht so unwahrscheinlich ist).
Oder eben nicht, wenn irgendwas aus (OS|JVM|Applikation) geupdated wird, weiß man im Voraus wann Zeitumstellungen sind.


----------



## Meniskusschaden (7. Nov 2018)

max40 hat gesagt.:


> das muss er auch nicht, weil die ganzen Informationen in java hinterlegt sein müssen.


Sind sie das?


max40 hat gesagt.:


> Woher soll java sonst wissen, das am Tag x eine Zeitumstellung ist.


Weiß "Java" das?


----------



## mrBrown (7. Nov 2018)

Meniskusschaden hat gesagt.:


> Sind sie das?


Ja: https://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html


----------



## Meniskusschaden (7. Nov 2018)

mrBrown hat gesagt.:


> Da wird man sich auch weiter im Kreis drehen


Das stimmt schon alles. Trotzdem kann es - je nach Zweck - gut genug sein. Im autarken militärischen Hochsicherheitsbereich wird man so etwas sicherlich solider organisieren. Für einen Raspi, der vielleicht die Rollädensteuerung der Gartenlaube variieren soll kann es aber ein pragmatischer Weg sein.


----------



## Meniskusschaden (7. Nov 2018)

mrBrown hat gesagt.:


> Ja: https://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html


Das hätte ich nicht erwartet. Also kann man einfach für einen gegebenen Zeitstempel den zugehörigen UTC-Offset abragen? Dann ist das Problem doch gelöst.


----------



## mrBrown (7. Nov 2018)

Meniskusschaden hat gesagt.:


> Das stimmt schon alles. Trotzdem kann es - je nach Zweck - gut genug sein. Im autarken militärischen Hochsicherheitsbereich wird man so etwas sicherlich solider organisieren. Für einen Raspi, der vielleicht die Rollädensteuerung der Gartenlaube variieren soll kann es aber ein pragmatischer Weg sein.


Was kann ein pragmatischer Weg sein, das im Kreis drehen?


----------



## mrBrown (7. Nov 2018)

Meniskusschaden hat gesagt.:


> Das hätte ich nicht erwartet. Also kann man einfach für einen gegebenen Zeitstempel den zugehörigen UTC-Offset abragen? Dann ist das Problem doch gelöst.


Ja, etwa so wie in #19, bricht halt bei der nächsten Änderung (dieses Jahr wären das drei mal passiert)


----------



## Meniskusschaden (7. Nov 2018)




----------



## Christoph74 (7. Nov 2018)

Erstmal danke an alle! 

So, dann hätten wir


```
GregorianCalendar gc_nach_umstellung = new GregorianCalendar();
            GregorianCalendar gc_vor_umstellung = new GregorianCalendar(2018,9,27);
           
            TimeZone tz = gc_nach_umstellung.getTimeZone();           
           
            System.out.println(tz.getOffset(gc_vor_umstellung.getTimeInMillis()));
            System.out.println(tz.getOffset(gc_nach_umstellung.getTimeInMillis()));
```
 
Ergibt als Output:
7200000
3600000

Somit kann ich ermitteln, ob an dem jeweiligen Tag ne Zeitumstellung war und dann entsprechend handeln (Uhrzeit der Umstellung ist ja immer zwischen 02 und 03 Uhr.


Merci!


----------



## mrBrown (7. Nov 2018)

Die alte date-API solltest du wie die Pest meiden (gegen letztere helfen aber immerhin Antibiotika...)

Hier ist eine Lösung mit der neuen time-API: https://stackoverflow.com/questions/44586105/java-api-to-get-daylight-saving-boundaries-for-a-year



Christoph74 hat gesagt.:


> Uhrzeit der Umstellung ist ja immer zwischen 02 und 03 Uhr


Lass solche harten Zahlen (und auch das Datum) am besten raus, die können sich durchaus ändern.


----------



## Xyz1 (7. Nov 2018)

Thallius hat gesagt.:


> DAs sind dann ca. 9000 Einträge pro Jahr. Das sollte also auch in 100 Jahren noch akzeptabel schnell sein und bis dahin bist du eh tot und es kann dir egal sein


Was wenn er 101 Jahre lebt? Dann bist Du schon tot, er noch nicht - und ihm kann es nicht egal sein. 
Allgemein sehr opportunistisch, aber vielleicht hattest Du gerade mal einen schlechten Tag....


----------



## Thallius (7. Nov 2018)

DerWissende hat gesagt.:


> Was wenn er 101 Jahre lebt? Dann bist Du schon tot, er noch nicht - und ihm kann es nicht egal sein.
> Allgemein sehr opportunistisch, aber vielleicht hattest Du gerade mal einen schlechten Tag....



Würde bedeuten das er jetzt 0 Jahre alt ist. Mathe ist auch nicht so deine Stärle oder


----------



## Senftube (22. Nov 2018)

Habe dieepostings oben zur quergelesen - sie beginnen auch nicht von Anfang an - strange.
Unter Unix/Linux gibt es das /usr/sbin/rtc-Kommando was die Zeit syncronisiert (im crontab).
Die zeiten, wann die Teitumstellung erfolgt ist in der Datei /usr/lib/tztab
definiert, siehe 'man tztab'. Hab unter windows nach rtc und tztab gesucht, gibt aber nichts vergleichbares.

Je nach* Locale* speichert Windows diese info im ordner
C:\Windows\SystemResources\Windows.Data.TimeZones\pris

Ds sind compilierte resourcendatein, die man freeware-Tools lesen kann.
http://www.kornzauber.de/extension/pri

Dann gibt es noch das doskommando tzutil.exe und tzsync.exe

ich wuerde mir die Infos aus den Link von mr. brown in einer Tabelle unter dem key Locale  ablegen mit den Values Tage und zeiten der umstellung. Dann kann man per program abhaengig von der Locale (da wo der P anzer gerade steht  oder was ist die konkrete anwendung ?) ) festellen ob am nächsten Tag und Wann eine Zeitumstellung erfolgen wird oder nicht - wenn e die anforderung ist, das VORHER zu wissen unde nicht erst nach der umstellung.


----------

