Domino 9 und frühere Versionen > ND7: Entwicklung

Ansicht

<< < (3/4) > >>

Bastel123:
Hallo,

für mich ist es kein NOGO ein Datum in ein Textfeld zu speichern.
Manchmal bietet es sich einfach an, wenn es nicht gerade mit Zeitzonen zu tun hat.

Man muss sich nur an das das Format "YYYY-MM-DD hh:mm:ss" halten. Dann hast man immer einen definierten Stand, stolpert nicht über Betriebssysteme und andere Einstellungen und kann sich leicht wieder ein Datum "zusammenbasteln"  ;D .

Gruß
Sebastian

koehlerbv:
Klasse. Und dann stellt jemand das OS auf eine andere Sprache / andere Zeiteinstellungen um ... Es ist ein NOGO (ausser zu Anzeigezwecken). Und was sollte es auch bringen ausser einem Haufen Ärger?

Bernhard

Tode:
@Bernhard: Wenn man es natürlich vor dem speichern in ein "definiertes" Format bringt, wie Sebastian geschrieben hat, dann gibt es durchaus Anwendungsfälle... Aber dann darf ich die Umwandlung halt NIE mit den Standard- Notes- Mitteln machen, sondern muss das Datum immer selbst manuell umwandeln...

Aber: Das ist wirklich die Ausnahme (mir fällt da die Übergabe eines Datums- Wertes per @DBLookup zusammen mit einigen anderen Werten des gleichen Dokumentes ein, oder das speichern z.B. History- Einträgen in einem Feld ala: 2011-12-08~Field 123 modified by Torsten~other infos )

Peter Klett:
Also mir fallen auch ein paar Probleme ein, die man sich einhandelt, wenn man Datum in Datumsfeldern hält, anstelle von Textfeldern. Eines aus der Praxis:

Dokumente haben einen Gültigkeitsbereich. Datum gültig von und Datum gültig bis.

Anhand dieser Felder rechnet ein Agent nachts einen Status in die Dokumente, ob das Dokument abgelaufen, gültig oder zukünftig ist.

Da soll dann zum Beispiel eine Arbeitsanweisung zum 10.12.2011 in Kraft treten. Dummerweise hatte der Benutzer eine andere Zeitzone (vielleicht wohnt er wirklich dort, oder er hatte ein Sommerzeitproblem (schlechtes Beispiel im Dezember, aber sei's drum), oder was auch immer). Anstelle des Gültigkeitsbeginns 10.12.2011 00:00:00 bekommt das Dokument den Gültigkeitsbeginn 09.12.2011 23:00:00. Der täglich laufende Agent erkennt dann, dass das Dokument ab 09.12.2011 gültig sein soll, und setzt dadurch den Aktuell-Status einen Tag zu früh. Da kann man sich nicht gegen wehren. Oder mit welcher Toleranz soll man rechnen? Eine Stunde? Zwei? Das wird immer unsauber sein (ich habe eine Anwendung gesehen, in der ein (nicht dummer) Entwickler Datumswerte generell mit der Uhrzeit 03:00:00 ergänzt hat, damit Schwankungen durch Sommerzeitfehler sich nicht negativ auswirken. Damit ist aber der tiefere Sinn eines sauberen Datumsfeldes ad absurdum geführt).

Jahrelang habe ich genau mit diesem Problem gekämpft, das immer im Frühling auftrat, weil wieder irgendein Kunde die Sommerzeiteinstellung nicht korrekt vorgenommen hatte. Dieses Problem führte teilweise soweit, dass der gesamte produktive Betrieb still stand, da die Ablösung eines wichtigen Einstellungsdokuments so geschickt erfolgte, dass das alte Dokument gestern ungültig wurde, das neue aber erst morgen gültig. Da muss man dann in einem ansonsten revisionssicheren System mit irgendwelchen Agenten, Smarticons oder anderen Schweinereien an den Dokumenten hantieren, damit der Laden wieder in Gang kommt. Immer wieder gern genommen.

Als ich dann das zweite große System anfing, hatte ich mir geschworen, nie wieder Datumsfelder zu verwenden. Dieses neue große System läuft seit sechs Jahren ohne Probleme, setzt allerdings eine durchgängige deutsche Einstellung auf den Clients und den Servern voraus. Diesen Haken habe ich (auch Dank der Beiträge hier im Forum) erkannt. Aber wenn ich mal wieder ein neues großes System anfangen würde, würde ich wieder Textfelder nehmen, jedoch die Umwandlung von Beginn an in eigenen Routinen vornehmen.

Und seien wir doch ehrlich. Eine Umwandlung von Datumsfeldern in Text erfolgt doch ständig. Sei es bei einem Datenaustausch über ASCII-Im- und Exporte, über eine URL o.ä.

Natürlich muss man, wie immer, die Rahmenbedingungen abstecken. Nutze ich ein Datum, um internationale Zusammenarbeit zu organisieren, brauche ich natürlich echte Datumsfelder mit Zeitzone, sonst ist das Chaos perfekt. Eher formalistische Anwendungen, die sich mit Arbeitsanweisungen, Revision, Prüfungen und solchen Dingen befassen, brauchen sie eher nicht.

Abhängig von dem Umfeld, in dem man sich bewegt, sind da natürlich die Befindlichkeiten unterscheidlich. Ein striktes Nein oder Ja kann es m.E. daher auch hier nicht geben. Und nicht alles, was falsch erscheint, ist auch wirklich falsch.

koehlerbv:
Peter, da hast Du Dir hinsichtlich er Zeitzone aber gerade ein ganz, ganz schlechtes Beispiel für Text als DT-Speicher herausgesucht.  Aber wirklich das allerschlechteste ...

Ich verweise jetzt mal auf das famous and most known EntwicklerCamp 2012 in Gelsenkirchen vom 26. bis 28. Maärz 2012. Ich spreche da nicht unzuverlässig wieder über "Notes und die Zeit" und werde Deine These da sehr gerne widerlegen. Laut derzeitigem Referentenplan hast Du da ja gerade auch Zeit ;-)

Aus wirklich langjähriger Erfahrung (in internationalen Umgebungen, die das ja jedesmal extrem verschärft) betone ich nochmals:
Das SPEICHERN von Datums-/Zeitwerten in Notes-Dokumenten ist ein NOGO.

Bernhard

PS: Peter, ich hoffe jetzt sehr, Du verstehst das nicht falsch. Du bist ja auch einer der grossen Erfahrungsträger - und damit wie ich jemand, der unwissentlich durchaus langjährig Missverständnisse mit sich herumschleppen kann.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete