 |
Calendar / Date und Zeitzonen
|
|
On Thu, 04 Sep 2008 07:43:27 +0200, Karsten Stöckmann <...@gmx.net
Hej,
folgendes Problem:
ich habe zwei Werte w1 und w2 (Calendar), deren Zeitzone GMT+0 ist. Nun
möchte ich prüfen, ob das Datum (und nur das) beider Werte identisch ist.
Beispiel:
w1: 02.09.08, 20:00h (GMT+0)
w2: 02.09.08, 23:00h (GMT+0)
In Zeitzone GMT+0 funktioniert das, sprich das Datum ist identisch; für
zb GMT+2 tut es das nicht, da hier durch die Verschiebung w2 bereits in
den 03.09. fällt (logisch: da ist es bereits 01:00h; auch
nachvollziehbar, wenn man das Datum über DateFormat entsprechend der
Zeitzone formatieren läßt).
Bislang vergleiche ich also, um ein korrektes Ergebnis entsprechend der
aktuellen Zeitzone (!) zu bekommen, nicht w1 und w2, sondern ich
formatiere beide über DateFormat als String und vergleiche die
Ergebnisse per equals. Allerdings kommt mir das reichlich umständlich
vor; gibt es eine einfachere Möglichkeit, die Calendar-Werte direkt
miteinander zu vergleichen, unter Berücksichtigung der Zeitzone?
Gruß aus Essen
Karsten
--
PGP Public Key ID 0x708CD1FE (pgpkeys.pca.dfn.de)
"When the light of day is dead, the spark of night ignites"
|
|
|
 |
On 4 Sep 2008 07:18:54 GMT, Manfred Schenk <...@gimli.derservermitdemlangennamen.de
Karsten Stöckmann <...@gmx.net
Mal ein paar verständnisfragen:
Wie prüfst du genau?
Sind weiterhin beide Werte in der selben Zeitzone oder willst du über Zeitzonen
hinweg vergleichen?
ciao,
Manfred
--
| Manfred Schenk | born between RFC638 and RFC640
| PGP-Keys unter |
| http://www.ZEROByte.de/pgp/ | WWW: http://www.ZEROByte.de/
|
 |
On Thu, 04 Sep 2008 09:59:42 +0200, Karsten Stöckmann <...@gmx.net
Manfred Schenk schrieb:
w1.get(Calendar.DAY_OF_YEAR) == w2.get(Calendar.DAY_OF_YEAR)
^ für meine Zwecke ausreichend. Hier entsteht genau das Problem: die
Werte w1 und w2 haben Zeitzone GMT+0 und bspw als DAY_OF_YEAR 248. Läuft
das Prog nun hier auf einem PC in Zeitzone GMT+2, dann ist der zweite
Wert aber eigentlich schon 249..
Nochmal zur Verdeutlichung:
w1: 02.09.08, 2100h, GMT+0, DOY 248
w2: 02.09.08, 2300h, GMT+0, DOY 248
-DAY_OF_YEAR 249.
Ersteres.
Gruß aus Essen
Karsten
--
PGP Public Key ID 0x708CD1FE (pgpkeys.pca.dfn.de)
"When the light of day is dead, the spark of night ignites"
|
 |
On Thu, 4 Sep 2008 10:26:04 +0200, "Hubert Partl" <...@boku.ac.at
Frage: Welche Gleichheit wuenschst Du Dir?
Wenn Du "Sonntag frueh in Essen" und "Sonntag Abend in Moskau"
als den gleichen Tag haben willst,
dann leg w1 als Calendar-Objekt mit der Zeitzone von London
und w2 als Calendar-Objekt mit der Zeitzone von Moskau an.
Wenn Du "Sonntag 1 Uhr Essen = Montag 23 Uhr Moskau" haben willst,
dann musst Du die Moskauer Zeit in die Essener Zeit umrechnen,
z.B. mit w2Essen.setTime( w2.getTime() )
wobei w2 die Zeitzone von Essen hat,
und dann w1 mit w2Essen vergleichen.
Oder habe ich da etwas falsch verstanden?
--
|
 |
On Thu, 04 Sep 2008 15:13:50 +0200, Karsten Stöckmann <...@gmx.net
Hubert Partl schrieb:
Siehe mein Posting von 1310h, da ist es näher erklärt. Ist mittlerweile
gelöst. :)
Gruß aus Essen
Karsten
--
PGP Public Key ID 0x708CD1FE (pgpkeys.pca.dfn.de)
"When the light of day is dead, the spark of night ignites"
|
 |
On Thu, 04 Sep 2008 12:31:42 +0200, Achim Peters <...@gmx.de
Karsten Stöckmann schrieb:
Ich verstehe nicht, was Du gerne als Ergebnis hättest. Soll Deine
Prüfung auf gleiches Datum bei
w1: 02.09.08, 20:00h (GMT+0)
w2: 03.09.08, 01:00h (GMT+2)
true oder false liefern?
Bye
Achim
|
 |
On Thu, 04 Sep 2008 13:10:06 +0200, Karsten Stöckmann <...@gmx.net
Achim Peters schrieb:
*seufz* mir fehlt heut etwas die Begabung, mein Anliegen richtig
auszudrücken.. :)
Es ist so:
Ich habe ein Array mit verschiedenen Elementen, die jeweils ein
Calendar-Objekt enthalten. Das Array ist aufsteigend vorsortiert. Jetzt
möchte ich dieses (flache) Array in ein Datenmodell einsortieren, das
aus Knoten (=Tage) besteht, die wiederum jeweils alle Element enthalten,
deren Datum an diesem Tag liegt. Bsp:
Montag, 01.09.08
Element 1 (01.09.08, 2000h UTC)
Element 2 (01.09.08, 2100h UTC)
Element 3 (01.09.08, 2300h UTC)
Dienstag, 02.09.08
Element 4 (02.09.08, 1000h UTC)
...
Die Calendar-Objekte der Elemente liegen in UTC vor, das Datenmodell
soll aber hinsichtlich der Zeitzone des Clients (!) sortiert sein, dh im
obigen Fall, daß natürlich das Element 3 bei GMT+2 eigentlich in den
Dienstags-Knoten gehört (2300h UTC = 0100h GMT+2).
Das Modell wird derart aufgebaut, daß das Array durchlaufen und für
jedes Element geschaut wird: ist mein Datum das gleiche wie das des
zuvor betrachteteten Elements? Wenn ja, dann kann ich getrost in den
zuletzt angelegten Knoten einsortieren, ansonsten (Tageswechsel) muß ein
neuer angelegt und das Element dorthin sortiert werden.
Der Vergleich zum Vorgänger, um zu entscheiden, wohin ein Element
gehört, ist also der Knackpunkt. Da die Daten selber in UTC vorliegen,
ich aber für die Zeitzone des Clients sortieren möchte, muß irgendwie
konvertiert werden, und ich suche nach einer geeigneten (oder besser,
der "geeignetsten") Methode, das zu tun.
Möglichkeit 1:
ich formatiere das Datum des aktuell betrachteten und des vorherigen
Elements über DateFormat und vergleiche die Strings über equals;
Möglichkeit 2:
ich stecke die UTC-Zeit des Elements in ein Calendar-Objekt der Zeitzone
des Clients und schaue mir dann DAY_OF_YEAR (und YEAR) an.
Bsp:
Calendar converted = Calendar.getInstance()
converted.setTimeInMillis(element.getTime().getTimeInMillis());
... // Vergleichen.
Hoffe, das war jetzt verständlich.. *seufz* :)
Gruß aus Essen
Karsten
--
PGP Public Key ID 0x708CD1FE (pgpkeys.pca.dfn.de)
"When the light of day is dead, the spark of night ignites"
|
 |
On Thu, 04 Sep 2008 13:49:49 +0200, Achim Peters <...@gmx.de
Karsten Stöckmann schrieb:
Dann interessiert Dich der ganze Calendar-Teil incl. Zeitzone des
Elementes *überhaupt nicht*, sondern Dich interessiert nur der zugrunde
liegende kanonische Zeitpunkt, vorzugsweise in Millisekunden seit
1.1.1970 0h UTC.
Zu diesem Zeitpunkt brauchst Du nun ein Datum in der Zeitzone des Clients.
Das ist Mist.
So ginge es.
Das würde ich beim Vergleich aber nicht jedesmal neu aus dem zuletzt
eingefügten Element ermitteln, sondern beim Erzeugen des Knotens aus dem
ersten eingefügten Element ziehen und am Knoten speichern, ggf. bereits
als Calendar-Objekt in der passenden Zeitzone oder als daraus
ermitteltes (YEAR, DAY_OF_YEAR)-Tupel.
HTH
Bye
Achim
|
 |
On Thu, 04 Sep 2008 14:18:46 +0200, Karsten Stöckmann <...@gmx.net
Achim Peters schrieb:
Ja, das dachte ich mir auch. :)
Gute Idee, heut Abend mal umsetzen.. Thx. :)
Gruß aus Essen
Karsten
--
PGP Public Key ID 0x708CD1FE (pgpkeys.pca.dfn.de)
"When the light of day is dead, the spark of night ignites"
|
 |
On Sat, 06 Sep 2008 21:57:31 +0200, Erhard Schwenk <...@fto.de
hoffentlich false.
02.09.08 20:00 (GMT+0) == 02.09.08 22:00 (GMT+2)
!
--
Erhard Schwenk
Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de/
APAYA running System - http://www.apaya.net/
|
 |
On Sun, 07 Sep 2008 00:19:30 +0200, Achim Peters <...@gmx.de
Und? Es ging um gleiches (Tages-)Datum, wie Du oben mitgequotet hast,
nicht um identischen Zeitpunkt.
Bye
Achim
|
|
|