UTC in Verbindung mit klimatologischen Kenndaten

[TheWeather]

Hallo zusammen,

angeregt durch diesen Beitrag von falk hier und hier nochmal als Direktlink zum Thema https://www.dwd.de/DE/leistungen/klimadatendeutschland/beschreibung_tagesmonatswerte.html habe ich mich gefragt, wie sich denn die Definition der klimatologischen Kenndaten dadurch verändern könnte oder wie diese Kenntage bei einer Messung in UTC (Universal Time Coordinated) überhaupt richtig zu berechnen wären.

Ich wusste, ehrlich gesagt, noch nichts von dieser DWD-Definition, dass der Tag messtechnisch gegen 23.50 Uhr (UTC) endet und am 23.51 Uhr (UTC) ein neuer (messtechnischer) Tag beginnt. Ich war immer noch in MEZ (Mitteleuropäische Zeit) oder MESZ (Sommerzeit) unterwegs. Allerdings vermute ich, dass diese Definition auf einer Richtline der WMO (World Meteorological Organization) beruht.

Es ist zwar erstrebenswert, eine einheitliche Regelung für die Erfassung von Wetterdaten weltweit an UTC festzumachen, aber die Kenntage können sich ja immer nur auf den Tagesverlauf einer Region beziehen und ein Begriff wie "Tropennacht" oder "Eistag" hängt ja immer mit der Zeitzone zusammen, in der man sich befindet.

Bei uns ist das noch relativ einfach, da wir ja eng an die GMT (Greenwich Mean Time) gekoppelt sind. Ein oder zwei Stunden Unterschied wären hier nahezu irrelevant. Eine Tropennacht z.B. in Neuseeland fände gemäß UTC mit 12 Stunden Zeitverschiebung statt, also eher mittags. Das kann ich mir nicht sinnvoll vorstellen.

Ich habe gegoogelt, aber ich finde keine eindeutigen Hinweise. Weiß jemand (eventuell mit Quellen), wie die meteorologischen (klimatologischen) Kenndaten eindeutig an die Messungen in UTC gekoppelt sind? Sind es nur Zeitzonen oder auch entsprechende Sommerzeit-Regelungen (die gibt es ja weltweit auch zuhauf), die dabei auf die zeitliche Ermittlung der Kenndaten angewendet werden müssen?

Vielen Dank, wenn jemand die Frage auflösen kann ...

Gruß Hans

[Holli]

Tropennächte sind keine Kenntage nach WMO. Außerdem sind sie ausdrücklich für die (lokale) Nacht definiert, nicht für den Tag nach WMO.

Einfluß hat diese Regelung aber auf warme und heiße Tage um den 180. Längengrad und östlich davon und auf kalte und Frosttage um den 0. Längengrad und östlich davon, denn die Wahrscheinlichkeit, daß dabei durch den Tageswechsel gleich zwei Tage betroffen sind, ist relativ hoch, weil lokale Nächte nun mal tendentiell kälter sind und lokale Tage wärmer. Eine einzelne Nacht mit durchgängig Frost generiert bei uns 2 Frosttage, an der amerikanischen Westküste aber nur einen. Bei den warmen und heißen Tagen ist es genau umgekehrt.

[TheWeather]

Hallo Dietmar,

das ist schon mal ein Anfang für mein Verständnis.

Wenn nun die WMO (daran angelehnt wahrscheinlich auch der DWD) für einige Messungen (meist Temperaturen) den Tag von 23:51 UTC Uhr bis 23:50 UTC des Folgetages festlegt (bei Niederschlägen Angabe der Summe um 5:50 Uhr UTC), dann bedeutet diese Festlegung für uns (Sommerzeit mal völlig außer acht gelassen), dass bei uns (meist EU-Raum, z.B. Berlin) der Tag von 0:51 Uhr bis 0:50 Uhr lokaler Zeit gerechnet wird. An der Westküste der USA (z.B. Los Angeles) müsste der Tag von 15:51 bis 15:50 des Folgetages lokaler Zeit gerechnet werden, in China (z.B. Peking) dagegen von 7:51 Uhr bis 7:50 Uhr des Folgetages in lokaler Zeit.

Dann ist aber bei uns zwar gerade mal Mitternacht vorbei, in Los Angeles ist es ist es morgens in der Frühe in Peking bereits später Nachmittag. Das macht ja SO keinen Sinn (oder ich hab's noch nicht kapiert ...).

Jede Region hat ihren lokalen Tag-/Nacht-Rhythmus, den man am einfachsten vielleicht mal am lokalen Sonnenhöchststand festmachen könnte (der nahezu immer gleich bleibt) und den Tag von 12 Stunden davor bis 12 Stunden danach beschreiben könnte, ohne die "Definition" eines "Tages" gemäß der Zeitrechnung bei der PTB (Physikalisch Technische Bundesanstalt) weiter zu komplizieren.

Anzugebende (lokale) Tageswerte oder auch (lokale) Nachtwerte müssen also irgendwie auch die lokalen Bedürfnisse (Tag-/Nacht-Rhythmus) der entsprechenden Region treffen. Hier kämen dann wenigstens die Zeitzonen ins Spiel - soll heißen, alle messen zwar im UTC-Raster, veröffentlichen aber dann doch lokale Werte.

Ist das so oder bin ich mit meiner Vorstellung jetzt komplett auf dem Holzweg?

Dann könnte man doch lieber gleich in lokaler Zeit rechnen, Tageswerte ausgeben und erst für den weltweiten Vergleich auf entsprechend synchrone Weltdaten "zurückrechnen" - was für weltweite Klimabewertungen sicher sinnvoll ist, aber als Anweisung zur lokalen Messung zu "Unzeiten" gemäß UTC sicher etwas am Thema vorbei geht. OK, Vieles geht automatisch und es muss niemand mehr irgendwelche Instrumente ablesen.

Korrelieren könnte man Messergebnisse auch immer noch, wenn man nur den Herkunftsort und den lokalen Zeitpunkt (mit oder ohne Sommerzeitumstellung) kennt, um weltweite Erkenntnisse ( wie warm war es am 24.12.2017 (UTC)) auf der Erde zu gewinnen.

Hier ist anscheindend irgendeine Kommission mal wieder über das Ziel hinausgeschossen, etwas verwenden zu wollen, das diese Kommission in der Anwendung selbst nicht beschreiben kann.

Das führt zur weltweiten Verwirrung und keiner weiß doch momentan wirklich, welche Klimadaten da wie, wo und wann zusammengeramscht werden.

Ich lasse mich gerne auch anderweitig überzeugen, aber eine einheitliche Festlegung zu Zeiten nach UTC scheint mir für die meisten Wetterdaten nicht notwendig.

Was soll ein Anwender in Kasachstan jetzt machen? Werte gemäß UTC (bei Zeitzone 7, 8 oder 9) jetzt selbst umrechnen, irgendwo hinmelden und hoffen, dass sie richtig eingeordnet werden?

Die meisten Fehlerquellen werden immer noch ausgeschlossen, indem man die Kirche im Dorf lässt und erst später (nach dem Eintreffen von Daten) einen Abgleich oder Plausibilitätsklärung macht, von welcher Weltwetterorganisation welcher Wert zu welchem Zeitpunkt gemeldet wurde. Das kann man ja auch nicht in einen Topf werfen.

Die Auswertung sollte schon später stimmen und da muss immer noch jemand drüber schauen, der sich auch mit "UTC" und den übermittelten Daten auskennt. Ich denke, das ist Tagesgeschäft ...

Na ja, hätte mich einfach weiter interessiert ...

Ich hab' quasi noch nichts so recht kapiert, wie man Tag/Nacht/UTC in einen Topf werfen kann.

Gruß Hans