Das Notes Forum
Domino 9 und frühere Versionen => ND8: Entwicklung - XPages => Thema gestartet von: Ruedi am 11.04.11 - 10:49:05
-
Greife ich über eine View Data Source auf eine Zeitspalte zu, wird der Inhalt dieser Spalte falsch angezeigt. Die angezeigte Zeit weicht um zwei Stunden von der in Notes gespeicherten ab. Zur Illustration habe ich eine Beispiel-Anwendung angehängt.
Als Workaround kann eine Textspalte in der View eingetragen werden [@Text(<time>; "T1")]. Dies funktioniert zwar, ist aber nicht wirklich befriedigend. Unklar ist mir auch, weshalb bei View Data Sources alle Spalten als [Text] ausgewiesen werden, bei Form Data Sources aber korrekt als [Text], [Date], [Time], [Number].
Kennt jemand das Problem? Und hat sogar eine Lösung?? Und würde diese erst noch mit mir teilen???
Ruedi
P.S.: Der Anhang war versehentlich verschlüsselt, ist jetzt aber lesbar.
-
Keine Berechtigung. DB verschlüsselt ?!?
-
OOoops! Sorry (und danke für den Hinweis).
Irgendwann lerne ich hoffentlich, dass lokale DBs standardmässig verschlüsselt werden. Jetzt ist der Anhang nicht mehr verschlüsselt.
Ruedi
-
Jetzt geht`s. Aber warum der immer 2 Std dazu addiert. Ehrlich gesagt: keine Ahnung :-:
-
Wenn man allerdings das Feld "zeit" in der Maske auf Datumsfeld umdreht, dann geht`s.
In den bestehenden Feldern steht z.Bsp. nur 02:30 drin. Nach der Änderung allerdings 02:45 14.04.2011 CEDT.
Vielleicht liegts daran.
-
Also wenn das Feld "Zeit" in der Form Text ist und Du es dann in der View als "Datum/Zeit" anzeigst,
a) KANN das nicht funktionieren
b) Ist das sehr PFUI.
Wenn Du Datums und/oder Zeitwerte speicherst, solltest Du auch den korrekten Datentyp dafür verwenden, sonst kommt es genau zu solchen Effekten.
-
@m3: wie kommst du denn darauf, dass das Zeit-Feld vom Typ Text ist? Wie du in der Beispiel-DB leicht selbst feststellen kannst, haben sowohl das Feld im Formular als auch die so erzeugten Felder im Dokument den Feldtyp Date/Time. Auch in der Spalte wird der Feldinhalt als Time angezeigt. Also nicht ganz so PFUI ;). Nachdem das geklärt ist, weisst du vielleicht auch, weshalb die Spalte in einer View Data Source trotzdem als [Text] erscheint (und eine Zeitspalte ohne Datum in XPages falsch angezeigt wird).
@klauss: Du hast recht: enthält der in der "Zeit"-Spalte angezeigte Wert auch einen Datumteil, funktioniert die Anzeige in XPages. Überraschend! Allerdings soll das Feld "Zeit" nur die Zeit (ohne Datum) enthalten. Und da in der Ansicht ein Datum dazuzuhängen, macht nicht eben Sinn.
Ruedi
-
@m3: wie kommst du denn darauf, dass das Zeit-Feld vom Typ Text ist?
Deswegen: Wenn man allerdings das Feld "zeit" in der Maske auf Datumsfeld umdreht, dann geht`s.
-
Und da in der Ansicht ein Datum dazuzuhängen, macht nicht eben Sinn.
Versteh ich jetzt nicht. Ich kann mir doch nur die Uhrzeit zeigen lassen.
-
Deswegen: Wenn man allerdings das Feld "zeit" in der Maske auf Datumsfeld umdreht, dann geht`s.
Tja, wenn klauss das Feld auf ein Datumsfeld umdreht, heisst das eben nicht zwangsläufig, dass es zuvor kein Datumstyp war ;). Ein Datumsfeld kann auch von "nur Zeit" auf "Datum+Zeit" geändert werden. Und interessanterweise verhält sich ein Datumsfeld mit Datums- und Zeitangabe anders als nur mit Zeitangabe. Aber ich bin immer noch auf der Lösungssuche...
Versteh ich jetzt nicht. Ich kann mir doch nur die Uhrzeit zeigen lassen.
Richtig! Aber wenn ich in der Spalte nur die Zeit anzeige (z.B. mit @Time(<datumsfeld>)), wird mir diese Zeit mit XPages wieder um zwei Stunden verrückt angezeigt. Irgendwie hat XPages in einer View Data Source nicht genügend Angaben um die Zeit korrekt zu interpretieren (ich muss mir wieder mal anschauen, welche Angaben zur Zeitzone Notes mit einer Zeit mitspeichert). Oder hast du es geschafft, auch in XPages die richtige Zeit zu erhalten?
-
Ja.
-
Ja.
Gratuliere! Ich schaffe es nicht, in XPages die Zeit korrekt anzuzeigen, wenn die Spalte, auf die ich mich beziehe, nur eine Zeitangabe enthält. Kannst du die NSF-Datei mit deiner Lösung hier publizieren? Vielen Dank.
-
Habe gestern leider schon alles wieder gelöscht :'(
-
Habe gestern leider schon alles wieder gelöscht :'(
Schade :'(! Dann gehe ich weiterhin davon aus, dass eine Spalte mit reiner Zeitinformation (ohne Datumsteil) in XPages nicht korrekt angezeigt wird. Bis ich eine bessere Lösung finde, werde ich eine Hilfsspalte benutzen, in der die Zeit in Text umgewandelt wird. Bin trotzdem weiterhin sehr interessiert an einer funktionsfähigen Lösung.
-
Fast geschafft! Verwende ich JavaScript anstelle von Simple Data Binding, erhalte ich die korrekte Zeit (vgl. auch beiliegendes Beispiel):
falsch:
value="#{rowEvent.Zeit}"
korrekt:
<xp:this.value>
<![CDATA[#{javascript:rowEvent.getDocument().getItemValueDateTimeArray ('zeit')}]]>
</xp:this.value>
Bleibt mir "nur" noch die Aufgabe, die Zeit vom Default Format "hh:mm:ss" ins Short Format ("hh:mm") zu bringen. Mal schauen, ob das mit einem XPages Data Converter funkioniert oder ob ich dazu JavaScript benötige. Falls jemand einen Tipp zu diesem letzten (?) Stolperstein hat, bin ich begeistert, ihn zu hören!
-
Soda, ich hab nochmal nachgedacht.
Ein Zeitfeld ohne Datum dürfte für die Default-Mechanismen problematisch sein, da diese sich bemühen, die korrekte Zeitzonen- und Sommerzeitregeln auf den Wert anzuwenden. Ich würde mal sagen, sie behandelen den Eintrag dann als GMT/UTC.
Damit bleibt Dir als Option nur, entweder mit Datum zu speichenr, damit die Default-Mechanismen damit umgehen können, oder - wie Du es nun eh schon machst - händisch drum rum coden (was vermutlich nur gut geht, solange alle in der gleichen Zeitzone und Sommerzeitzone sind).
-
Gehört die Zeitzonen-/DST-Information denn zum Datum oder zur Zeit? Meines Erachtens zur Zeit, da ja 12:00 letztlich nur mit dem Zusatz der Zeitzone/DST die Zeit klar festlegt.
Als wir vor Jahren ein Problem mit DST hatten, musste ich mich mit der Frage beschäftigen, wie Zeitangaben in Notes gespeichert werden. Ist aber schon (zu) lange her. Mal schauen, ob ich Daniel Nashed dazu fragen kann.
Tatsache ist, dass bei einem Zeitfeld ohne Datum in den Field Properties nur die Zeit angezeigt wird (z.B. 21:00:00), bei einem Datum nur das Datum (z.B. 31.12.2011) und nur bei Datum+Zeit die Zeitzone angegeben ist (z.B. 31.12.2011 21:00:00 CET). Ob das aber nur eine Frage der Anzeige oder wirklich der gespeicherten Information ist, kann ich nicht sagen.
-
Prinzipiell würde sie zur Zeit gehören, da geben ich Dir recht.
A-Bär: die DST Info ist auch vom Datum abhängig, da DST Anfang/Ende in verschiedenen Jahren unterschiedlich sein kann ...
-
Angaben zur Zeitzone (und damit auch zu DST) gehören immer zu einem Zeitpunkt, also dem "Gesamtpaket". Wenn es heute bei uns 23 Uhr ist, dann ist in diesem Moment 1 Uhr des Folgetags in Moskau.
Intern gerechnet wird sowieso immer mit einer Datumsseriennummer, deren gebrochenen Teil das darstellt, was wir als "Uhrzeit" interpretieren. Nur an das komplette Konstrukt kann man Zeitzonenangaben binden.
Wir verwenden reine Datums- oder Uhrzeitangaben im Alltagsleben, allerdings haben diese mit der rechnerischen Darstellung nichts mehr gemein.
Bernhard
-
Spannender Exkurs! Trotzdem nochmals zurück zum ursprünglichen Problem:
- Im Notes Client wird ein Zeitfeld (ohne Datumsteil), in das ich 21:00 eingetragen habe, als 21:00 angezeigt.
- Das gleiche Feld wird in XPages als 21:00 angezeigt, wenn ich Simple Data Binding nutze und die Datenquelle eine Form ist.
- Ist die Datenquelle hingegen eine View, wird 23:00 angezeigt (Zeitdifferenz wohl abhängig von meiner Zeitzone/DST).
- Ist die Datenquelle eine View und verwende ich die Funktion getItemValueDateTimeArray, wird 21:00 angezeigt.
Vorsichtige Schlussfolgerung: Simple Data Binding auf eine Zeitspalte über eine View Data Source ist fehlerhaft. Einverstanden? Oder greift die Schlussfolgerung doch zu kurz?
-
23:00:00 Uhr ist ja eigentlich nicht speicherbar, was Notes da bietet, ist eine reine Anzeigegeschichte.
Steht nur die Information 23:00:00 Uhr zur Verfügung, so wird tatsächlich gespeichert
30.12.1899 23:00:00 oder genauer: 0,958333333333.
Und offensichtlich greifen bei der Auswertung der Zeitzone jetzt unterschiedliche Mechanismen (unter der Voraussetzung, dass explizit gar keine Zeitzone angegeben wurde): Einmal "fehlende Zeitzone = UTC" und zum anderen "fehlende Zeitzone = Zeitzone des Betriebssystems".
Auch denkbar: Die (Default-)Zeitzone geht bei einem Verfahren einfach verloren.
Da ich nicht weiss, wie das bei XPages intern (!) gehandhabt wird, wage ich jetzt keine Aussage zu "Bug oder kein Bug". Irritierend ist es auf jeden Fall.
Bernhard
-
Einfach mal einen PMR aufmachen und den Support in Verzweiflung stürzen (Zeitzonen, GMT und Localization - Dinge die US-Entwicklern fürchten wie der Teufel das Weihwasser).
-
;D
Die amerikanischen Kollegen sind doch sooo stolz, dass sie "vier" Zeitzonen haben. Dafür kennen sie die anderen nicht ... und ihr Weltbild gerät ins Wanken, wenn sie nach Hawaii fliegen ;D
Bernhard