wieder mal Probleme mit Datum/Zeit Feldern

[Demian]

Moin,moin,

ich habe in meiner Maske ein Datumsfeld, das auf Anzeige "nur Datum" steht (wegen Anzeige und Sortierung in Ansicht). Wenn ich ein neues Dokument manuell erstelle, enthält das Item richtiger Weise z.B. 01.05.2009 (siehe Screenshot manuell.jpg). Ich musste aber einige Dokumente aus einer Exceltabelle importieren. In diesen Doks steht in dem Item z.B. 01.05.2009 00:00:00 CEDT.

Das führt dazu, dass in meiner Ansicht bei der Kategorie Jahr, 2009 2x erscheint. Jetzt hab ich nen Agenten drüber laufen lassen und das Feld mit Cdat(NotesDateTime.DateOnly) überschrieben. Er behält aber die Uhrzeit trotzdem im Item. Wenn ich eines dieser Dokumente manuell bearbeite, das Datum lösche und das Jahr 2009 manuell eintrage, hat er wieder das 00:00:00 CEDT mit drin, obwohl das bei ganz neuen Doks nicht so ist.

Statt cdat habe ichs auch schon mit Datevalue probiert. Ebenso statt .DateOnly mit .LSLocalTime. Es bleibt dabei. Er behält die Uhrzeit mit drin. Im Debugger zeigt er für das Item aber seltsamerweise nur das Datum an.

Wie zum Geier krieg ich es hin, dass er nur das Datum in das Feld schreibt, ohne Uhrzeit und nicht als Text?

[koehlerbv]

Sowie Du das im Backend machst, bekommst Du Datum UND Uhrzeit.

Das ist auch in keinster Weise störend. In Ansichten musst Du (als ordentlicher Programmierer) ja sowieso darauf reagieren, ob da überhaupt ein gültiger DT-Wert steht. Du kannst dann dort auch gleich noch mit @Date einen gültigen DT-Wert normieren. Auch das ist ein "must" in Ansichten, in denen eine Spalte NUR das Datum ohne Zeitkomponente anzeigen soll.

Bernhard

PS: Niemals das Backend ausser Acht lassen 

[Demian]

Sowie Du das im Backend machst, bekommst Du Datum UND Uhrzeit.

Aber bei den importierten Doks auch im Frontend. Nur bei ganz neuen Doks nicht.

(als ordentlicher Programmierer)

Gut, dass ich Personaler bin  Ich denke, wenn ich das Vollzeit machen würde und nicht nur hier und da alle paar Wochen, würde sich sowas eher einprägen.

In Ansichten musst Du  (als ordentlicher Programmierer)ja sowieso darauf reagieren, ob da überhaupt ein gültiger DT-Wert steht.

Das macht ja Notes bei der Eingabe schon. Aber wie könnte ich das in Ansichten abfragen, @isdate oder sowas gibts ja nicht direkt.

Du kannst dann dort auch gleich noch mit @Date einen gültigen DT-Wert normieren. Auch das ist ein "must" in Ansichten, in denen eine Spalte NUR das Datum ohne Zeitkomponente anzeigen soll.

Ich habe das bis jetzt immer nur in der Spalteneigenschaft gemacht mit Anzeige "nur Jahr". Habe jetzt in der Formel noch ein @year um das Feld gesetzt. Jetzt ignoriert er die verschiedenen Items . Aber sollte es nicht auch nur über die Spalteneigenschaft funktionieren? Ansonsten ist die Eigenschaft ja eigentlich für die Füße, oder nicht? 

Oh mann, manchmal könnt ich mir wirklich in den H..... treten. Zig verschiedene Agenten probiert und dann ist es eigentlich so einfach.

PS: Niemals das Backend ausser Acht lassen

Auch hier bin ich leichgläubigerweiße davon ausgegangen, dass .dateonly auch only date zurückgibt

[Demian]

Du kannst dann dort auch gleich noch mit @Date einen gültigen DT-Wert normieren.

Vor lauter Frust das Wichtigste vergessen: Danke für den Tip 

[koehlerbv]

Hallo Demian,

wollten wir nicht sowieso telefonieren?  

Zu Deinen Anmerkungen:
Import ist Backend. Und wenn der Time-Part erstmal drin ist ... Du darfst nicht vergessen: Nicht nur in Notes sind DT-Werte reelle Zahlen. Datumsseriennummern eben. und x,0 ist eben xx.xx.xxxx 00:00:00.

Gut, dass Du Personaler bist - darum ist ein Programmierer ja auch kein Personaler, weil er davon bestenfalls eine gewisse "Überblicks-Kennung" hat - aber keine wirkliche Ahnung. Und vice versa. Du brauchst einen Programmierer an Deiner Seite, mit dem Du absprichst (was Du einfach selber machen kannst und wo eben das Spezialwissen gefragt ist). An der falschen Stelle sparen wird teuer. Frag Deine Nachbarabteilung (die Finanzer), die kennen sich mit diesen Rechnungen noch besser aus.

Bei der Eingabe ... Nun, das ist eine reine Frontend-Geschichte (und ja, das lässt sich auch über das Backend ... aber das wäre hier nicht zielführend). Gehe einfach davon aus, dass DT-Werte aus beiden Komponenten bestehen. Du weisst im Voraus ja nie, was Dir später im Backend noch Knüppel zwischen die Beine werfen kann.

Prüfung auf gültige DT-Werte: Einfachst und ein must have, weil man ja nie weiss ...
@If (@IsTime (dtvalue); @Date (dtvalue); <DeineReaktion>)
Hierbei passiert beides: Wenn der DT-Wert ein gültiger ist, wird nur die Datumskomponente angezeigt, im Else-Zweig musst Du Deine Reaktion für den Fall einbauen, dass statt 20.05.2009 dort "Im Himmel ist Jahrmarkt" eingetragen ist.

Wegen den Spalteneigenschaften: Das erfordert nun tiefere Kenntnisse der view indices in Notes. Im Index sind da für die Spalte verschiedene Dinge gespeichert - bei Dir also einmal DD.MM.YYYY und einmal DD.MM.YYYY HH:MM:SS. Angezeigt wird laut Forderung nur das Jahr, aber die Basis ist ... na, Du hast das sicher erkannt: Es sind zwei Paar Schuhe und ergibt auch mehr als eine Kategorie.

Aus meinen Vorträgen "Notes und die Zeit" muss ich endlich mal einen AtNotes Best Practice Artikel machen  

HTH,

Bernhard

[Demian]

Hallo Demian,

wollten wir nicht sowieso telefonieren?  

Ja, hatte geplant, dich nachher mal telefonisch zu überfallen, wenn ich daheim bin

Gut, dass Du Personaler bist - darum ist ein Programmierer ja auch kein Personaler, weil er davon bestenfalls eine gewisse "Überblicks-Kennung" hat - aber keine wirkliche Ahnung. Und vice versa.

oh ja ich weiß, aber sag das mal den Zuständigen  Auch wenn ich in einigen Stellen über die "Überblicks-Kennung" hinaus bin, hapert es an anderen schon an den Basics. Hängt auch immer damit zusammen, ob ich Personaltechnisch viel zu tun hab und dann was programmieren soll, oder ob ich viel Zeit hab. Bei letzterem gehe ich das ruhiger und konzenrtierter an. Wahrscheinlich wär ich dann auch früher auf das @year gekommen.

Bei der Eingabe ... Nun, das ist eine reine Frontend-Geschichte (und ja, das lässt sich auch über das Backend ... aber das wäre hier nicht zielführend).

In dem Fall bin ich ja hingegangen und hab das Datum komplett rausgeholt, gespeichert, das Dok geschlossen, wieder geöffnet und das Datum neu eingetragen. Trotzdem wird es bei den importierten Doks anders gehandelt, wie bei ganz neuen. Sowas kann ich nicht wirklich nachvollziehen 

Prüfung auf gültige DT-Werte: Einfachst und ein must have, weil man ja nie weiss ...
@If (@IsTime (dtvalue); @Date (dtvalue); <DeineReaktion>)
Hierbei passiert beides: Wenn der DT-Wert ein gültiger ist, wird nur die Datumskomponente angezeigt, im Else-Zweig musst Du Deine Reaktion für den Fall einbauen, dass statt 20.05.2009 dort "Im Himmel ist Jahrmarkt" eingetragen ist.

Hhm, aber bei Datums/Zeit feldern sind doch eigentlich keine falschen Eingaben möglich, oder nicht? Jedenfalls meckert er bei mir beim Speichern direkt.

Wegen den Spalteneigenschaften: Das erfordert nun tiefere Kenntnisse der view indices in Notes. Im Index sind da für die Spalte verschiedene Dinge gespeichert - bei Dir also einmal DD.MM.YYYY und einmal DD.MM.YYYY HH:MM:SS. Angezeigt wird laut Forderung nur das Jahr, aber die Basis ist ... na, Du hast das sicher erkannt: Es sind zwei Paar Schuhe und ergibt auch mehr als eine Kategorie.

Ja, so macht das Sinn. Aber für mich als Laien ist Jahr = Jahr. Aus welchem Wert er das Jahr zieht sollte dann relativ schnuppe sein. Theoretisch müsste ja dann @Year auch je nach Item-Wert anders reagieren.

[koehlerbv]

Hhm, aber bei Datums/Zeit feldern sind doch eigentlich keine falschen Eingaben möglich, oder nicht? Jedenfalls meckert er bei mir beim Speichern direkt.

Soweit richtig. Aber denke immer an Frontend versus Backend. Ein einfacher Agent
FIELD Datum := "Smoke On The Water";
und nix stimmt mehr. Und dafür reicht ein einfacher Fehler eines Programmierers.

Wegen anrufen: Ich bin "nach Diktat verreist", heute also nicht mehr erreichbar. Freitag bin ich in Besprechungen (ein idealer Tag dafür  ), Montag in München. Am Dienstag bin ich aber wieder im Büro (statt für zwei Tage in Mainz). Und das auch nur, weil ich heute erfahren habe, dass ich kommende Woche auch nach drei Wochen mein Auto, das mir ein "ganz besonderer Optimist" in Mainz in Klump gefahren hat, dort noch nicht aus der Werkstatt abholen kann: An dem fast neuen Auto entpuppen sich wohl mit jedem entfernten Teil immer weitere Schäden ... Jetzt sind wir schon bei 11.000 EUR ...

Bernhard

[Demian]

Soweit richtig. Aber denke immer an Frontend versus Backend. Ein einfacher Agent
FIELD Datum := "Smoke On The Water";
und nix stimmt mehr. Und dafür reicht ein einfacher Fehler eines Programmierers.

Eigentlich geh nur ich an die DB's ran. Aber im Prinzip haste da recht. Das ist ein weiteres Problem, es gibt keinerlei Vorgaben und da ich noch nie mit irgendwem im Team gearbeitet hab, weiß ich da auch nicht worauf zu achten ist.

Am Dienstag bin ich aber wieder im Büro (statt für zwei Tage in Mainz).

Schade, sonst hätt man sich auch einfach mal auf ein Bierchen treffen können in Mainz Dann werde ich mich Dienstag melden.

Jetzt sind wir schon bei 11.000 EUR ...

Ui, da wird sich die Versicherung desjenigen aber freuen und gleich den Prozentsatz erhöhen. Nur den Stress hast ja leider trotzdem du.

[koehlerbv]

Eigentlich geh nur ich an die DB's ran. Aber im Prinzip haste da recht. Das ist ein weiteres Problem, es gibt keinerlei Vorgaben und da ich noch nie mit irgendwem im Team gearbeitet hab, weiß ich da auch nicht worauf zu achten ist.

Das kann man ändern 

Schade, sonst hätt man sich auch einfach mal auf ein Bierchen treffen können in Mainz Dann werde ich mich Dienstag melden.

Was spricht dagegen? Der "Knaller" hat einen Besuch bei einem Kunden in Darmstadt verhindert, der nachzuholen ist. Ich bin also sowieso länger in der Gegend, als nur den Leihwagen abzustellen und mein "wieder neues" Auto abzuholen.
Hat sonst noch jemand im Grossraum Frankfurt / Wiesbaden / Mainz Bedarf?

Ui, da wird sich die Versicherung desjenigen aber freuen und gleich den Prozentsatz erhöhen. Nur den Stress hast ja leider trotzdem du.

Jo. Ich habe in letzter Zeit selten soviel Formulare ausfüllen müssen, Statements schreiben (der "Optimist", der "danach" sowas von korrekt reagiert hat und sich selber nicht erklären kann, wie er auf die Idee kam zu versuchen, den fliessenden Verkehr einer vierspurigen Strasse aus einer Nebengasse gleich auf die vierte Spur zu überqueren ...), Umplanungen machen müssen und so weiter. Allein schon, dass man beim Leihwagen auf die Nase fallen kann: In ganz Mainz war an diesem Sonnabend das einzig in Frage kommende Auto ein Golf 5. Das Auto war ja okay, aber hat für zwei Seiten einen riesigen Nachteil: Für mich: Halbe PS-Zahl, bis auf die Strassenlage und das Sitzgefühl nicht vergleichbar (das ist mir aber recht egal in so einer Situation). Für die "gegnerische" Versicherung: Das Auto ist zu teuer. Die Telefoniererei ...
Der Unfall"gegner" hat sicherlich Scherereien. Und eine höhere Klasse bei der nächsten Abrechnung. Wenn alles vorbei ist, muss ich ihn aber mal anrufen: Auch wenn er mich mit seinem Auto frontal (an meiner Vorderachse) getroffen hat, dürfte sein Auto doch auch sehr arg gelitten haben. Ich hoffe, er fährt ohne Vermessung damit nicht mehr herum.

Bernhard

[Demian]

Das kann man ändern 

Wenn du damit auf eine Schulung hinaus willst, das ist ja der Grund, warum ich dich anrufen werd 
Wobei ich nicht glaube, dass man sowas in einer Schulung wirklich vermitteln,bzw. verinnerlichen kann. Denke, dafür muss man schon wirklich über längere Zeit im Team arbeiten und damit gezwungen sein bestimmte Regelungen einzuhalten. Ich habe mir zwar schon angewöhnt bei Script viel zu dokumentieren, habe aber oft auch das Problem, dass ich gar nicht weiß, wie ich etwas am besten beschreiben soll.

Was spricht dagegen? Der "Knaller" hat einen Besuch bei einem Kunden in Darmstadt verhindert, der nachzuholen ist. Ich bin also sowieso länger in der Gegend, als nur den Leihwagen abzustellen und mein "wieder neues" Auto abzuholen.
Hat sonst noch jemand im Grossraum Frankfurt / Wiesbaden / Mainz Bedarf?

Dagegen spricht nichts, aber für mich als Autolosen wär Mainz optimal gewesen, da ich aus Mainz-Kostheim komm.  Ansonsten gerne auch Frankfurt/Wiesbaden oder irgendwo, wo man mit der Bahn gut hinkommt.

Jo. Ich habe in letzter Zeit selten soviel Formulare ausfüllen müssen, Statements schreiben (der "Optimist", der "danach" sowas von korrekt reagiert hat und sich selber nicht erklären kann, wie er auf die Idee kam zu versuchen, den fliessenden Verkehr einer vierspurigen Strasse aus einer Nebengasse gleich auf die vierte Spur zu überqueren ...), Umplanungen machen müssen und so weiter.

Ja, und das bezahlt dir keiner und ob der Kunde Verständnis für sowas hat ist auch immer so ne Sache. Wenigstens hat der Schuldige seinen Fehler eingesehen und nicht noch auf stur gestellt.

[koehlerbv]

Wenn du damit auf eine Schulung hinaus willst, das ist ja der Grund, warum ich dich anrufen werd 

Darüber können wir natürlich auch gerne reden (und warum das gerade besonders gut passt, da ich jetzt für längere Zeit immer wieder in der Nähe von Frankfurt zu tun haben werde), aber ich spielte eigentlich auf das Bier an: Dann nehme ich mir eben ein Hotel in Mainz, wo ich die Nacht vor der Autoabholung und dem Aufbruch nach Darmstadt und dann "homeward bound" verbringe. Auf das gemeinsame Bier kam es mir an  Wenn das topographisch-zeitlich schon so danach schreit 

Bernhard

PS: He, den Rest machen wir jetzt aber per eMail. Wir missbrauchen gerade AtNotes, und ich bin Moderator ... Ich darf das gar nicht!

[pram]

um auf das Problem zurück zu kommen:

Ein Datum ohne zeit setzt du z.B. mit

dim dObj as new NotesDateTime("01.01.2009")
call dObj.setAnyTime()
call doc.replaceItemValue("Datum", dObj)

Eine "Mischform". d.h. einmal Datum, einmal Datum und Zeit im selben Feld können allerdings Probleme beim Sortieren in Ansichten etc machen und AFAIK ändern sich Felder mit Zeit wenn sich die Zeitzone ändert. Hier bin ich mir jetzt nicht 100%ig sicher, aber ich glaube mal gelesen zu haben, dass aus dem 01.01.2009 00:00 schnell mal ein 31.12.2008 23:00 wenn du auf einen Server in einer anderen Zeitzone replizierst.

Gruß
Roland