Datums- und Zeitformate #37
Comments
|
Siehe auch http://www.w3.org/TR/NOTE-datetime (das kurze Dokument stützt sich ebenfalls auf RFC 3339). |
|
Und noch zwei Hinweise auf die XML Schema Spezifikation (ebenfalls basierend auf ISO 8601): Das läuft im Ergebnis erfreulicherweise alles auf das gleiche hinaus. (Vorgreifend: Für JSON-LD würde ich xsd:date bzw. xsd:dateTime im @context angeben wollen.) |
|
Die Unix-Zeit ist auch sehr komfortabel, weil sie unabhängig von Zeitzonen und Zeitumstellungen ist und sich zudem gut verarbeiten lässt. Nachteil ist die schlechte Lesbarkeit durch den Menschen. |
|
@mionysos Dazu muss ich sagen: Der Nachteil macht Unix-Zeit aus meiner Sicht unbrauchbar. Datums-Strings in Standardformaten sollten auf jeder erdenklichen Plattform mit vertretbarem Aufwand verarbeitbar sein, z.B. auch um sie in Unix-Timestamps umzuwandeln. Ich denke, wir können bei "natürlichen" Zeiten wie z.B. Start und Endzeitpunkten einer Sitzung die Zeitangaben ohne Zeitzonen- bzw. UTC-Offset-Angabe (Sommer-/Winterzeit) machen, da eine Angabe in "Ortszeit" hier nachvollziehbar wäre. Anders ist es bei technisch motivierten Angaben wie z.B. Datum und Zeit der letzten Änderung einer Datei. Hier sollte, um Missverständnisse zu vermeiden, eine Zeit verwendet werden, die zweifelsfrei einem exakten UTC-Zeitpunkt zugeordnet werden kann. |
|
@marians Lesbarkeit durch Menschen halte ich nur insofern für wirklich wichtig, als dies das Debugging erleichtert. Verzicht auf Zeitzonen-/Offset-Angabe halte ich für ungünstig, da dann die Interpretation unnötig Wissen im Client voraussetzt. Wenn gleichzeitig ohnehin für last-modified exakte Zeitpunkte angegeben werden, dann gewinnt man durch einen solchen Verzicht auch nicht viel. |
|
@akuckartz Ich muss mich noch mal konkretisieren. Im Fall eines Objekt-Änderungsdatums beispielsweise sehe ich es auch so, dass eine Datum/Uhrzeit-Kombination einschließlich Zeitzonen-Information ausgegeben werden MUSS. Sonst kann beispielsweise Cache-Validierung nicht funktionieren. Für einige Datumsangaben oder auch Zeitangaben wird jedoch die Zeitzone keine Rolle spielen. Wenn am 1. September um 18 Uhr eine Sitzung in Bielefeld stattgefunden hat, ist klar, dass damit Ortszeit gemeint ist. Es dürfte übrigens auch Datenbestände geben, in denen gar keine Zeitzoneninformation vorhanden ist, weil beispielsweise eine Zeitangabe einfach im Format "YYYY-mm-dd HH:MM:SS" gespeichert wurde. Um diese Information per OParl-Schnittstelle ausgeben zu können, sollte man nun nicht etwa Information, die gar nicht gespeichert ist, dazuerfinden müssen. |
|
@marians Ich stimme zu, dass keine Information "dazuerfunden" werden soil oder darf. Eine RIS-Instanz wird aber regelmäßig wissen, zu welcher Zeitzone sie gehört. Wenn ich damit falsch liege, dann möge man mich widerlegen. Die Ausgabe ohne Zeitzone sollte nur dann erfolgen, wenn die RIS-Instanz diese tatsächlich weder kennt noch einfach bestimmen kann. Dass eine Sitzung z.B. in Bielefeld stattgefunden hat sollte man nicht wissen müssen, um einen Zeitstempel auch absolut interpretieren zu können. |
|
Workshop: |
|
chapter_8020.md ist angelegt und mit erstem Inhalt gefüllt. |
An verschiedenen Stellen wird ein Tages-Datum mit bzw. ohne Uhrzeit angegeben. Das Format sollte spezifiziert werden. Beispiel:
Sitzung start: Datum und ggf. Uhrzeit des Anfangszeitpunkts der Sitzung. Beispiel:
Drucksache (date) : Datum der Veröffentlichung. Beispiel:
Das letzte Beispiel entspricht offenbar dem in ISO 8601 (gleich EN 28601) spezifizierten erweiterten Format für ein Datum ohne Zeitangabe mit Mittelstrich als Trennzeichen.
Noch besser ist ein Verweis auf RFC 3339 (http://www.ietf.org/rfc/rfc3339.txt), dieser Standard bezieht sich auf ISO 8601.
The text was updated successfully, but these errors were encountered: