JDBC: Resultset beim Thema MEZ&MESZ

[rh-spirit]

Hi,

irgendie komme ich zur Zeit nicht aufs Java.Sun.Forum, deshalb poste ich mein Anliegen schon einmal hier.

Es geht um die JavaAPI der Datenbankschnittstelle.

Folgendes: Ich habe eine Oracle DB und lese über Java den zurückgegebenen Cursor (->ResultSet in Java) einer
Prozedur aus. Der Inhalt um den es mir hier geht sind zwei Spalten "MEZ" und "MESZ" (OracleKalenderobjekt) in denen logischerweiße Zeiten eingetragen sind.

Die API bietet die Möglichkeit mit REsultSet.getString / .getDate /.getTimestampt / formatter.format(.getObject)
die Zeit&Datum auszulesen.
ABER: Hat irgendjemand mal versucht im Bereich der Winter-Sommerzeitumstellung (bzw.andersrum) Werte auszulesen?? Die JavaAPI liefert immer einen MESZ komformen (ich nehme an das liegt an der Systemzeitzone&locale) Wert zurück.

Beispiel:

(MEZ Zeiten) (MESZ-Zeit als Hilfe)
in DB: 27.03.2005 01:45 in Java: 27.03.2005 01:45 01:45
27.03.2005 02:00 27.03.2005 03:00 03:00
.... 02:15 03:15 03:15
27.03.2005 03:00 03:00 04:00
03:15 03:15 04:15

Seht ihr was ich meine?? Ab 2:00 wird auf MESZ 3:00 gestellt. Das gibt das Java auch grandios aus.
Warum aber??? Warum verfälscht es meinen DB-Inhalt?? Blöderweiße aber auch nur in dieser Zeitumstellungsphase.
(in MESZ gibt es kein 27.03.2005 02:15 sondern nur 03:15 ). Daher kommt dann auch noch ein sinnloser "Verdopplungseffekt" zustande..


Hat jemand eine IDee, wie ich an die puren Daten komme?
Kann ich JaVA sagen: Lass den Scheiss mit MESZ??

Ich glaube mit etwas Handwerk wie mit Java-Calendar den DB-Inhalt jedesmal umzutransformieren und wieder zürück ist das Problem umgehbar. Aber Perfomancetechnisch der halbe Tod und programmiertechnisch sinnloses und unsauberes Gehacke.

Für Ideen und vorallen änhlichen Erfahrungen bin ich Dankbar.

G'sundes Neues noch allen !!!

 

[rh_spirit]

DB: MEZ--------------------------in Java:----------------(MESZ)
27.03.2005 01:45--------27.03.2005 01:45-----------01:45
---------------02:00-----------------------03:00-----------03:00
---------------02:30-----------------------03:30-----------03:30
---------------03:00-----------------------03:00-----------04:00
---------------03:30-----------------------03:30-----------04:30

Wie kann man hier ordentliche Tabellen machen, wenn kein TAB geht?

 

[Bleiglanz]

wenn, dann musst du für die eine Spalte einen Calender mit der DayLightsavings (manuell einstellen) verwenden und für die andere nicht, und noch dazu einen herumhack um rs.getDate()

Frage: was sind denn die "puren" Daten in den beiden Spalten?

Wärs nicht besser UTC oder sowas zu verwenden und beim hineinschreiben schon alles aufzulösen??

BTW: ich dachte bisher immer, dass fast alle Programmierer auf der Welt das Problem der doppelten / fehlenden Stunde bei der Zeitumstellung aus Unwissenheit oder Faulheit einfach ignorieren, ich übrigens auch

 

[rh_spirit]

Ganz links ("in DB:") sind die Originaldaten.

-genau das mit dem Gehacke&Calender wollte ich vermeiden (eigentlich sollte das auch nicht notwendig sein, wenn ich die eigentlich korrekten Daten aus der DB bekommen würde)

-ist UTC nicht deprecated?

-Am liebsten würde ich es auch ignorieren Aus der Sicht der Informationstechnologie hätte WI&SO Zeit nie eingeführt werden sollen
-Aber wenn man leider mit rechnen&operieren muss kommt man nicht drumherum. Ich saß lange bis ich meinen Algorithmen die Umstellung eingeprägt hatte (vorallen die Phase an sich) und DANN MUSS ICH feststellen, daß die JAVA-API ohne meinen WIllen einfach Zeugs umändert anstatt mir den reellen in der DB gespeicherten Zeitpunkt wiederzugeben.

 

[rh-spirit]

Ich habs mal mit dem Calender probiert...
allerdings nützt das nichts, da ich dem Calender ja schon falsche "Werte" übergeben würde. Ich könnte sonstwas für Sachen im Programm dann machen, aber das Problem liegt eindeutig an der Java-Schnittstellen-Api, die ja schon mit dem alleinigen Versuch Werte zu holen, jene in MESZ "umwandelt"
(jedenfalls in der Umstellungsphase). Ob über String/long/date/timestamp, immer kommt 03:30 statt 02:30 .
Das ist ein echtes Problem langsam. Vorallen was mich ärgert, warum von Java automatisert veränderte Werte kommen. Sowas darf nicht sein. Ich will die Originaldaten aus der DB!!!

 

[thE_29]

Verschoben nach JDBC!

 

[Bleiglanz]

kann eigentlich nicht sein: Java weiss - ohne manuellen Eingriff - gar nichts von der Winterzeit/Sommerzeit Umstellung

eher ein Oracle Effekt

http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10749/ch4datetime.htm#i1006760

The TIMESTAMP WITH TIME ZONE and TIMESTAMP WITH LOCAL TIME ZONE datatypes have the following behavior:

If a time zone region is associated with the datetime value, then the database server knows the Daylight Saving Time rules for the region and uses the rules in calculations.

 

[rh-spirit]

Verdammt, du hast Recht!

Klingt natürlich plausibel.
Bisweilen dachte ich, das die API Schnittstellenbeschreibung Voll und Ganz verantwortlich für den DAtenaustausch ist. Das Oracle trotzdem noch mitmischen kann wusste ich nicht.
Jetzt wird mir auch klar, warum man bei rs.getDate/timestamp einen Calender/Zeitzone mit übergeben werden kann. Rein theoretisch könnte ich eine Zeitzone einstellen, die keine Wi&So Umstellungen macht, aber dann müsste ich immernoch wieder umtransformieren. Trotzdem läßt mich der Gedanke mit den Original-Datenbank-Inhalt nicht in Ruhe:
Zum Beispiel in PL/SQL Developer wird der Inhalt korrekt angezeigt wird. Warum übergibt Oracle hier die korrekten Werte, bzw. was teilt deren Schnittstelle der DB mit, das das Problem nicht auftritt. Bzw. dann wird es doch in Java hoffentlich eine Konfigurationsmöglichkeit geben?

Im übrigen Danke auch für den Hinweis.
Das hat das Problem wenigsten genauer eingegrenzt.

 

[rh-spirit]

Warum geht das eigentlich nicht??

TimeZone tz = TimeZone.getTimeZone("Etc/UTC");
        Calendar cal = GregorianCalendar.getInstance (tz);
        ...

        ResultSet.getTimestamp("MEZ",cal);

Leider gibt mir das auch nicht die Original MEZ Zeit heraus, sondern auch Zeitzonenformatiert (eine Stunde früher).
Hat natürlich den Vorteil das die doppelten Stunden nicht auftreten. Arbeiten kann man dann aber auch nicht damit.[/quote]

 

[Bleiglanz]

welchen Datentyp hat eigentlich die Spalte in der DB?

und wer in der ganzen Angelegenheit verfügt überhaupt über die Information, dass die Umstellung am 27.März war??

 

[rh-spirit]

Oracle-Datentyp: Date

Am 27.03.2005 war WZ->SZ Umstellung.
Prinzipell weiß ich oder das Programm das natürlich nicht. Aber in der DB sind wie gesagt zwei Spalten. Eine mit dem MEZ Zeitstempel und die andere mit MESZ. Suche ich im Monat März/April nach der Umstellung, so muss nur auf einen Unterschied der beiden Spalten geachtet werden. Findet man einen, so war es 02:00 und man kann dementsprechend mit dem gewünschten Handling beginnen.
DAs funktioniert natürlich nur, wenn die Originaldaten auslesbar sind. Da Oracle scheinbar für 02:00 gleich 03:00 zurückgibt, tritt die Zeit von 03:xx zweimal auf (siehe Beispiel zuvor), und der Unterschied wäre erst ab der umgestellten Zeit feststellbar.

 

[rh-spirit]

Ich glaube mir leuchtet die Lösung ein:

Wenn in Java der Oracletyp"Date" immer mit einen bestimmten CalendarObjekt formatiert zurückkommt (default, also ohne Angabe Calendar, scheint also die ORacleZeitzone zu sein),
dann könnte ich doch einen Calendar mit Zeitzone MEZ nehmen.
Allerdings habe ich diese Zeitzone in den 3oo Typen nicht gefunden. Bzw. einen Calender, der unsere Zeitzone GMT+1 ohne "Daylightsaving" benutzt. Leider habe ich auch keine Methode gefunden, mit der man den Calender irgendwie auf daylightsaving "off" stellt. Wie das intern zum Beispiel PL&SQL Developer macht weiss ich nicht. Scheinbar kann der besser mit dem OracleDatentyp"Date" umgehen.

 

[rh-spirit]

Schade, ich hatte es doch gefunden, den Zeitzonentyp="CET".
Dieser gibt die Zeit ohne Sommerzeit aus.
01:00 ist 01:00
03:00 ist 03:00
ABER: In der Umstellungsphase gibt es auch hier Probleme:
02:15 ist 03:15.
Somit bin ich wieder am Ursprung meines Problems, daß wieder doppelter 03:xx Uhrzeiten auftreten, da er 02:xx umformatiert, da diese nicht "existieren".

Was soll ich denn nun machen ??

ICH HASSE WZ&SZ Umstellung!!!!!!!!