Einführung
Sie denken vielleicht, dass der Umgang mit Datum und Uhrzeit einfach ist. Wir haben eine Minute, die 60 Sekunden dauert, eine Stunde mit 60 Minuten, einen Tag mit 24 Stunden, eine Woche mit 7 Tagen, einen Monat mit 28 bis 31 Tagen und so weiter.
Hier ist sicherlich kein Hexenwerk erforderlich…
Nun, nichts könnte weiter von der Wahrheit entfernt sein!
Wir zeigen die Fallen und Fallstricke in Bezug auf Datum und Uhrzeit auf, auf die Sie während der Anwendungs- und Backend-Entwicklung stoßen können.
Maßeinheiten
Beginnen wir mit den Maßeinheiten, von der kleinsten bis zur größten.
Sekunden und Millisekunden
Die kleinste täglich verwendete Einheit ist eine Sekunde. Es ist auch die Basis der Unix-Zeit.
In einigen Programmiersprachen wie Java ist die gebräuchlichste Einheit jedoch eine Millisekunde (1/1000 Sekunde), wie beispielsweise bei der Methode System.currentTimeMillis().
Diese Abweichung kann zu vielen Fehlern führen.
Wenn Sie den numerischen Wert von außerhalb Ihres Systems erhalten, ist möglicherweise nicht auf den ersten Blick klar, welche Maßeinheit er verwendet, selbst nach dem Lesen der Dokumentation!
Sehen Sie sich das Feld DATUM in den Spalten SMS- und MMS-Inhaltsanbieter (Datenbank) an. In beiden Dokumenten heißt es nur:
Allerdings benötigt die SMS Millisekunden, während die MMS Sekunden verwendet. Überrascht? Nun, es kann passieren, insbesondere wenn solche APIs von verschiedenen Leuten entworfen werden.
Wie können Sie mit solchen Fällen umgehen? Und wie kann man sie vermeiden?
Glücklicherweise können wir mehrere allgemeine Regeln formulieren:
Stellen Sie immer das Format der eingehenden Daten sicher.
Überprüfen Sie es einfach, da die Dokumentation möglicherweise falsch und/oder veraltet ist. Es ist normalerweise sehr einfach, einen Fehler zu erkennen, beispielsweise ein Datum, das 50.000 Jahre zu weit in der Zukunft liegt, wenn man während der Entwicklung danach sucht. Dieses Ergebnis tritt auf, wenn Millisekunden beispielsweise als Sekunden behandelt werden.
Wenn Sie Einfluss auf die Seite haben, die die Werte sendet (z. B. wenn das System gerade entworfen wird und noch niemand es nutzt), ziehen Sie die standardisierten Textformate in Betracht.
Hier lege ich Wert auf Standardisierung (z. B. ISO 8601) und nicht auf einige benutzerdefinierte Formate (wir werden dieses Thema später erweitern). Nach ein paar Jahren arbeitet möglicherweise niemand mehr aus dem ursprünglichen Team an diesem Projekt, und das Textformat ist für neue Entwickler leicht zu verstehen, da sie sich die Dokumente nicht ansehen müssen.
Numerische Formate können jedoch bei leistungskritischen Geräten besser sein.
**Verwenden Sie dedizierte Klassen für den Umgang mit Datums-/Uhrzeit-/Dauerwerten anstelle von rohen Ganzzahlen.
**In der Java-Welt haben wir ein java.time-Paket mit vielen nützlichen Klassen wie Instant oder Duration. Wenn es eine Ganzzahl namens zB gibt. eventDuration, es ist nicht bekannt, ob es Sekunden oder Millisekunden speichert – oder vielleicht sogar Tage?
Wenn Sie mit Rohwerten (Ganzzahlen, Long-Werten usw.) arbeiten müssen, die Sie nicht einfach vollständig umgestalten konnten, wie z. B. Legacy-Code, schließen Sie die Maßeinheit mit den Variablen-/Feldnamen ein .
Beispielsweise ist „eventDurationSeconds“ eindeutig.
Schaltsekunden
Sie haben wahrscheinlich schon von Schaltjahren gehört. Sie unterscheiden sich von „normalen“ dadurch, dass sie einen zusätzlichen Tag länger sind. Wir haben auch Schaltsekunden!
Sind sie länger als Nicht-Schaltsekunden?
Nun, es kommt darauf an!
Beginnen wir zunächst mit ein wenig Theorie. Die Erde wird langsamer; Eigentlich handelt es sich nicht um eine philosophische Aussage, sondern um eine wissenschaftlich belegte Tatsache. Es heißt Delta-T.
OK, was bedeutet das also in der Praxis für uns? Nun, unsere Zeitmaßeinheiten haben eine standardisierte Länge. Die Basiseinheit ist eine Sekunde, die wie folgt definiert ist:
Die Zeitdauer von 9.192.631.770 Perioden der Strahlung entspricht dem Übergang zwischen den beiden Hyperfeinniveaus des fundamentalen ungestörten Grundzustands des Cäsium-133-Atoms. (Quelle: bipm.org)
Diese Dauer ist konstant und informiert alle anderen von Sekunden abgeleiteten Einheiten, z. Eine Minute besteht aus 60 Sekunden, eine Stunde besteht aus 60 Minuten (3.600 Sekunden) und so weiter.
Wenn sich die Erde jedoch verlangsamt (und der Tag länger wird), müssen wir dieser Verlangsamung irgendwie Rechnung tragen, um sicherzustellen, dass die von unseren Einheiten gemessene Zeit mit der Realität übereinstimmt. Dies geschieht durch das Einfügen zusätzlicher Sekunden – der Schaltsekunden.
Es gibt nur 2 verfügbare Plätze für Schaltsekunden im Jahr: Ende Juni und Dezember. Das Ende bedeutet den letzten Tag (30. bzw. 31.) kurz nach 23:59:59 UTC (daher variiert die Ortszeit).
Nach diesen normalerweise letzten Sekunden wird die zusätzliche Schaltsekunde eingefügt, bevor zum nächsten Tag übergegangen wird. Wir können also 23:59:60 haben (61 Sekunden in einer Minute – wenn wir von 0 an zählen).
Da die Verlangsamung nicht konstant ist, werden die Schaltsekunden unregelmäßig eingefügt. Der letzte Vorfall (zum Zeitpunkt der Erstellung dieses Artikels im April 2021) ereignete sich im Dezember 2016, also vor mehr als vier Jahren. Der vorletzte fand jedoch im Juni 2015 statt, mit nur einem Unterschied von 1,5 Jahren zwischen den beiden.
An einigen Orten, an denen wir die Zeit einstellen können – wie bei physischen Wanduhren oder einigen Framework-APIs – gibt es möglicherweise keine Möglichkeit, die Zeit mit der Schaltsekunde zu beobachten und/oder einzustellen.
Zum Beispiel unterstützt die altmodische Date-Java-Klasse sogar doppelte Schaltsekunden – der Bereich reicht von 0 bis 61, also sind 62 Sekunden möglich!
Die moderne Instant-Klasse aus dem java.time-Paket stellt Programmierern jedoch keine Schaltsekunden zur Verfügung. Die Schaltsekunde erstreckt sich gleichmäßig über die letzten 1.000 Sekunden des Tages (diese Sekunden sind länger).
Beachten Sie, dass die Schaltsekunde theoretisch auch negativ sein kann. Aber bisher ist es noch nicht passiert.
Das bedeutet, dass eine Minute aus 59 Sekunden bestehen kann, was zu großen Problemen führen kann. Wenn beispielsweise eine Aktion für 23:59:59.001 Uhr geplant ist und sich herausstellt, dass die gewünschte Zeit nicht existiert …
Glücklicherweise können analog zur Ausbreitung auch die sichtbaren Sekunden verkleinert werden, da sie für Programmierer völlig transparent sind.
Wir wissen, dass es die 61. Sekunde geben kann, aber was ist mit der 62.? Nun, in der Dokumentation heißt es:
Es ist äußerst unwahrscheinlich, dass zwei Schaltsekunden in derselben Minute auftreten, aber diese Spezifikation folgt den Datums- und Zeitkonventionen für ISO C.
Tatsächlich haben wir in der C-Spezifikation einen Bereich von [0, 61]. Aber warum? Die gleiche Frage beschäftigte Paul Eggert, den Autor von tzdata (Zeitzonendatenbank) im Jahr 1992. Wie wir im Archiv lesen können:
* „Weil es tatsächlich zwei Schaltsekunden in einem Jahr gab (an verschiedenen Tagen) und jemand im ANSI C-Komitee dachte, dass sie am selben Tag kamen.“ * – Quelle groups.google.com.
Dieser kleine Interpretationsfehler, der vor mehreren Jahrzehnten aufgetreten ist, ist noch heute sichtbar, da die neue Implementierung mit diesen Standards abwärtskompatibel sein muss.
Gehen wir zu anderen Randfällen in der App- und Backend-Entwicklung über.
Die Tage
Die Minuten und Stunden beinhalten keine unerwarteten Fälle, also springen wir zu den Tagen.
Was ist ein Tag? Es kommt darauf an! Man kann sagen, dass es 24 Stunden von 00:00:00 bis 23:59:60 dauert (einschließlich der Schaltsekunde?). Nun, ob Letzteres generell zutrifft, der Tag dauert nicht immer 24 Stunden, sondern kann auch 23, 25 oder sogar 21 und 27 sein! Warum diese Werte? Die Antwort ist…
Sommerzeit
Die sogenannte DST oder „Sommerzeit“ stellt die Uhren in wärmeren Monaten vor, um den Stromverbrauch zu senken. Die Dunkelheit beginnt später als in der „normalen“ Zeit (ohne Sommerzeit). Heutzutage ist die Notwendigkeit der Sommerzeit umstritten, da sie viele Nachteile mit sich bringt. Einige Länder haben aus diesem Grund kürzlich sogar aufgehört, die Sommerzeit einzuhalten (z. B. Russland im Jahr 2014).
Was sind die Probleme mit der Sommerzeit? Mal sehen!
Ich werde nicht auf Dinge wie vergessene manuelle Einstellungen von Wanduhren oder verspätete öffentliche Verkehrsmittel eingehen, sondern mich stattdessen auf Aspekte im Zusammenhang mit der Backend- und App-Entwicklung konzentrieren.
Sie denken vielleicht, dass wir in der Sommerzeit die Uhren um eine Stunde vorstellen. Das ist nicht immer der Fall! Es gibt Orte auf der Welt, an denen der Unterschied 3 Stunden (wie Casey) oder 30 Minuten (wie Lord Howe Island) beträgt.
Die Sommerzeit kann, nicht ganz wie der Name vermuten lässt, auch einen Teil des Frühlings oder Herbstes umfassen, ist aber im Allgemeinen mit den wärmeren Monaten verbunden. Das wiederum hängt von der Hemisphäre ab.
Während es in Europa einen Sommer gibt, gibt es in Australien einen Winter und umgekehrt. Um das ins rechte Licht zu rücken: Die australische Sommerzeit fällt in den europäischen Winter!
Darüber hinaus hängt die zeitliche Definition des Sommers von der Gerichtsbarkeit ab. In allen Ländern der Europäischen Union wird die Zeit gleichzeitig umgestellt, sodass der Zeitunterschied zwischen Berlin und London beispielsweise immer 1 Stunde beträgt, egal ob wir im Sommer oder Winter sind.
Aber bedenken wir den Zeitunterschied zwischen Sydney und London. In diesem Fall kommt es auf den Tag im Jahr an! Das liegt daran, dass die Sommerzeit in Sydney zu anderen Zeitpunkten beginnt und endet als in London.
Inspiration: timeanddate.com
Zum Beispiel haben wir ab Januar einen Unterschied von 10 Stunden. In Sydney gilt zu dieser Zeit die Sommerzeit, in London jedoch nicht. Ab Ende März beginnt in London die Sommerzeit, während der Bundesstaat in Sydney unverändert bleibt, sodass sich der Unterschied auf 9 Stunden verringert. Dann, im April, hört Sydney auf, die Sommerzeit einzuhalten, sodass wir 8 Stunden haben. Wir haben 3 verschiedene Offsets. Auf die Frage nach dem Zeitunterschied zwischen Sydney und London gibt es also drei Antworten!
Länder wie die USA, EU-Mitgliedstaaten oder Australien haben, sagen wir, stabile Gerichtsbarkeiten in Bezug auf die Sommerzeit. Es ist im Voraus bekannt, wann der Übergang stattfindet. Dies ist jedoch nicht immer der Fall, da es in einigen Ländern zu unerwarteten Gesetzesänderungen kommen kann. Im Jahr 2020 beispielsweise haben sich auf Fidschi die Regeln geändert, da die Ankündigung erst einige Monate vorher erfolgte.
Noch kompliziertere Situationen gibt es in einigen islamischen Ländern, in denen der Ramadan offiziell gefeiert wird. Wenn sie auch die Sommerzeit einhalten, kann diese ausgesetzt werden (für die Zeit des Ramadan).
Das bedeutet, dass der Übergang zur Sommerzeit mehr als einmal (hin und her) und sogar einige Male im Jahr erfolgen kann. Darüber hinaus wird der Ramadan nach dem islamischen (Mond-)Kalender berechnet. Vorhersagen werden zur Berechnung der Ramadan-Grenzdaten verwendet und sind möglicherweise nicht immer genau. Für Palästina beispielsweise fällt die Vorhersage im Jahr 2020 um etwa eine Woche zu kurz aus. Änderungen wurden erst wenige Tage im Voraus übernommen.
Die meisten Systeme nutzen die IANA-Zeitzonendatenbank als Quelle für die Übergangsmomente zur Sommerzeit. Normalerweise gibt es jedes Jahr ein paar Aktualisierungen in dieser Datenbank.
Beachten Sie, dass der Umgang mit der Sommerzeit Auswirkungen auf Algorithmen haben kann. Betrachten wir einige typische Szenarien.
Wenn wir einen Alarm für eine bestimmte Uhrzeit (z. B. 02:30 Uhr) geplant haben, kann es sein, dass ein solcher Zeitpunkt nicht existiert (wenn die Zeit während des Übergangs zur Sommerzeit von 02:00 auf 03:00 Uhr geändert wird) oder es existiert zweimal, wenn die Zeit rückwärts geändert wird. Wenn beispielsweise die Sicherung nicht durchgeführt wird oder Medikamente nicht oder doppelt verabreicht werden, können die Folgen schrecklich sein.
Ein weiterer häufiger Effekt besteht darin, dass zyklische Zeitänderungen ausgelöst werden, wenn sich der Benutzer in der Zeitzone befindet, in der die Sommerzeit gilt. Wenn Sie beispielsweise planen, dass ein Build auf bitrise.io um 10:00 Uhr gestartet wird, kann es sein, dass er plötzlich um 11:00 Uhr startet.
Dies geschieht, weil die Logik unter der Haube die Sommerzeit nicht kennt und die für den Benutzer sichtbare Zeit erst beim Rendern der Benutzeroberfläche berechnet wird. Der absolute Zeitpunkt ist immer derselbe, aber die für den Benutzer sichtbare Zeit ändert sich je nach Sommerzeit. Normalerweise ist es nicht das, was Kunden erwarten.
Die Wochen
Was ist der erste Tag der Woche? Wenn Sie in Europa leben, würden Sie wahrscheinlich Montag sagen. In den USA ist es Sonntag und in arabischen Ländern Samstag. Diese Fakten können sich auf die Algorithmenkonstruktion und/oder -darstellung von Kalendern auswirken.
Was ist mit der Wochennummer im Jahr? Sie denken vielleicht, dass alles am 1. Januar beginnt.
Wie Sie vielleicht schon vermutet haben, ist dies auch nicht immer der Fall!
Laut ISO-Standard muss die 1. Woche des Jahres den Donnerstag enthalten. Beispielsweise fällt im Jahr 2021 der 1. Januar auf einen Freitag und gehört somit zur letzten Woche des Vorjahres. Die erste Woche des Jahres 2021 begann am 4. Januar! Allerdings verwenden nicht alle Gebietsschemata in dieser Hinsicht dieselben Regeln wie der ISO-Standard.
Die Monate
Der gregorianische Kalender, der in den meisten Teilen der Welt verwendet wird, hat 12 Monate, von Januar bis Dezember. Andere Kalenderarten können jedoch mehr Monate haben. Beispielsweise kann der hebräische Kalender 13 Monate haben. Der 13. (in der IT-Welt) heißt Undecimber.
Die Jahre
Normalerweise dauert das Jahr 365 Tage. Jedes durch 4 teilbare Jahr (z. B. 2020, 2024 usw.) ist jedoch ein Schaltjahr mit 366 Tagen (mit 29 Tagen im Februar anstelle der normalen 28). Wenn es jedoch durch 100 teilbar ist (2100, 2200 usw.), ist es KEIN Schaltjahr. Aber ? Wenn es durch 400 teilbar ist (2000, 2400 usw.), ist es ein Schaltjahr.
Glücklicherweise müssen (und sollten!) Sie nicht versuchen, solche Unterscheidungen selbst umzusetzen. Sie sollten Datumsklassen/Funktionen verwenden, die in der jeweiligen Programmiersprache bekannt sind.
Es gab viele spektakuläre Fehler in bekannten Diensten im Zusammenhang mit falschen Schaltjahrberechnungen. Es gibt sogar einen Begriff: Schaltjahrproblem.
Die Zeitzonen
Die Ortszeit hängt vom Längengrad ab. Während es an einem bestimmten Ort Mittag ist, ist es auf der anderen Seite der Welt auch Mitternacht.
Es ist unpraktisch, die Uhren auf Reisen ständig umzustellen, deshalb wurde der Globus in Zonen unterteilt, die die Gebiete abdecken, in denen die gleiche lokale offizielle Zeit herrscht.
Zonengrenzen entsprechen in der Regel den Landesgrenzen bei kleinen Ländern oder einigen geografischen Regionen in den größten (wie Australien, USA oder Russland).
Quelle: timeanddate.com
Aus politischen und wirtschaftlichen Gründen weicht die offizielle Zeit mancherorts erheblich von der „legitimen“ Zeit ab (wobei nur Längengrad/Sonnenzeit berücksichtigt wird). In Spanien beispielsweise ist die Zone dieselbe wie in den meisten kontinentalen Mitteleuropas und nicht im Vereinigten Königreich, das je nach Längengrad näher liegt.
Die meisten Zeitzonen haben integrale Offsets (die Differenz zur UTC – einer Standardzeit), z. in Berlin +1 Stunde (+2 in der Sommerzeit) oder -3 Stunden in Buenos Aires (Argentinien, keine Sommerzeit). Der Versatz kann jedoch halbe Stunden umfassen, z. in Mumbai (Indien) haben wir +5:30 Uhr (keine Sommerzeit).
Als ob das noch nicht genug wäre, sind auch Quartiere möglich, denn in Kathmandu (Nepal) haben wir +5:45h!
Zum Zeitpunkt des Schreibens gibt es glücklicherweise keine feineren Offsets mehr. Früher gab es sie jedoch, beispielsweise +0:20 in den Niederlanden.
Aufgrund der Tatsache, dass wir 24 Stunden auf der Uhr haben, könnte man meinen, dass es sich auch um eine Reihe möglicher Verschiebungen handelt. +12:00 und -12:00 zusammen ergibt 24.
Der größte Zeitabstand zwischen den Zeitzonen beträgt jedoch 26 Stunden!
Dies ist möglich, weil wir einen Versatz von +14:00 haben. Es wurde von mehreren Ländern Ozeaniens übernommen, da diese eher mit Australien verbunden sind. Daher ist es praktischer, ein paar Stunden Unterschied zu haben als mehr als 20, was in den meisten Fällen zu einem anderen Datum führt.
Betrachten wir einen Flugverbindungsfinder. Bei Hin- und Rückflügen können die Nutzer sowohl Abflug- als auch Rückflugdatum/-zeit wählen. Es kann offensichtlich sein, dass die Rückkehrzeit nach der Abreise liegen muss.
Natürlich könnte das nicht weiter von der Wahrheit entfernt sein!
Beachten Sie, dass diese Zeiten in lokalen Zeitzonen angegeben sind.
Sehen Sie sich dieses Beispiel an:
Abfahrt von Tokio um 00:30 (Offset +09:00) nach San Francisco (Offset -07:00)
Ankunft in San Francisco um 18:00 Uhr, am Vortag in Ortszeit!
Rückkehr aus San Francisco um 19:50 Uhr (immer noch früher im Vergleich zur ursprünglichen Abreise)
Sie können also irgendwohin gehen und gestern zurückkehren. Sehen Sie sich dieses Beispiel an:
Benennung der Zeitzone
Ein weiterer potenzieller Grenzfall bei der App-/Backend-Entwicklung, mit dem Sie möglicherweise konfrontiert werden, hängt mit der Benennung von Zeitzonen zusammen.
Vielleicht ist Ihnen aufgefallen, dass wir eine Zeitzone anhand ihres Offsets aufrufen können, z. B. +01:00 oder durch seine Kennung, z. Europa/Berlin. Beachten Sie, dass die letztere Notation mehrere Vorteile bietet: Sie enthält Informationen über Sommerzeitübergänge (Berlin hat im Sommer einen Offset von +02:00) und enthält auch historische Daten.
Zum Beispiel scheinen heutzutage sowohl die Zonen Europa/Warschau als auch Europa/Berlin identisch zu sein. Beide haben das ganze Jahr über gleiche Verschiebungen, wobei die Sommerzeitübergänge auch immer zum gleichen Zeitpunkt stattfinden.
Allerdings war das in der Vergangenheit nicht immer der Fall! Zum Beispiel gab es 1977 in Berlin überhaupt keine Sommerzeit, aber in Warschau wurde sie vom 3. April bis zum 25. September eingehalten (völlig anders als heute).
Beachten Sie, dass Zeitzonenkennungen auf Städtenamen basieren. Dies ist beabsichtigt, da sich Ländergrenzen viel häufiger ändern als Städtenamen.
Zum Beispiel hat sich die Krim tatsächlich von der Ukraine in Russland geändert, aber die Städtenamen bleiben unverändert. Die Zone Europa/Simferopol kann unabhängig davon genutzt werden, ob wir aktuelle oder historische Daten benötigen.
Tag vs. Nychthemeron, Periode vs. Dauer
Sagen wir, etwas hält einen Tag. Wenn es also um 09:15:00 Uhr beginnt, können wir 24 Stunden hinzufügen und die Endzeit ermitteln (in diesem Fall ausschließlich 09:15:00 Uhr am nächsten Tag).
Nun, es ist nicht immer so einfach! Bedenken Sie, dass es zu einem Übergang zur Sommerzeit kommen kann, wenn die Uhr künstlich vorwärts oder rückwärts verstellt wird. Das bedeutet, dass der Tag normalerweise 24 Stunden dauert, aber gelegentlich auch 23, 25 oder noch seltsamere Werte wie 27 oder 23,5 Stunden (erinnern Sie sich an Casey und Lord Howe?).
Bei der Implementierung der Geschäftslogik ist es wichtig, Tage nicht blind als 24 Stunden zu behandeln. Sie sollten hierfür die entsprechenden Datums-/Uhrzeit-APIs verwenden. In Java haben wir beispielsweise unterschiedliche Klassen:
Zeitraum, der Kalendertage darstellt – perfekt für Dinge wie die Abonnementgültigkeit, die in Tagen, Monaten oder Jahren gemessen wird
Dauer, die eine kontinuierliche Zeit darstellt, z. 24 Stunden, unabhängig vom Datum im Kalender. Es eignet sich perfekt zum Messen von Aktionsspannen, z. B. Reisen oder der Zeit seit Geräte-/Programmstart.
Einige Sprachen haben unterschiedliche Wörter für sonnenbeschienene Zustände (auf Englisch – Tag) und aufeinanderfolgende 24 Stunden (auf Englisch – Nychthemeron, aber es wird nicht häufig verwendet).
Datums-/Uhrzeitdarstellung:
Quelle: xkcd.com
Bei der Kommunikation mit anderen Systemen, beispielsweise über die REST-API, ist es wichtig, sich über Datenformate zu einigen. Wenn als Datum der 12.10.2021 angezeigt wird, liegt es möglicherweise entweder im US-Format (12. Oktober) oder im britischen Format (10. Dezember) vor.
Es ist besser, eine eindeutige Darstellung zu verwenden!
Für Datum und Uhrzeit haben wir den ISO 8601-Standard. Beachten Sie, dass nicht nur absolute Datums-/Zeitangaben standardisiert sind, sondern auch Zeiträume. Es ist auch wichtig, den richtigen Typ zu verwenden – lokal (zur Darstellung von Daten wie Wecker-Auslösezeiten oder Geburtsdaten) oder zoniert (zur Darstellung von Zeitpunkten wie dem Beginn eines Ereignisses oder dem Aufnehmen von Bildern).
Benutzerdefinierte, nicht standardisierte Formate führen normalerweise zu Verwirrung und Fehlern, also vermeiden Sie sie.
Bei der Anzeige von Datum und Uhrzeit in der Benutzeroberfläche müssen Sie das Gebietsschema des Benutzers berücksichtigen. Das angezeigte Format hängt von der Sprache und Region ab. Schauen Sie sich die folgenden Beispiele an, die sich alle auf dasselbe Datum beziehen:
Es gibt vordefinierte Formattypen, die von Datums-/Uhrzeitbibliotheken bereitgestellt werden, wie z. B. FormatStyle in java.time. Verwenden Sie sie, wenn möglich. Andernfalls können Sie mithilfe standardisierter Mustersymbole individuellere Formate erstellen. Weitere Einzelheiten finden Sie in der CLDR-Dokumentation.
Bemerkenswert ist, dass es bei Monaten, Quartalen und Wochentagen auch eigenständige Varianten gibt. Sie sind nur in einigen Sprachen von Bedeutung (nicht in Englisch). Auf Polnisch heißt April beispielsweise kwiecień – dies ist eine eigenständige Version. Wenn es jedoch mit einem Tag verbunden ist (z. B. 18. April), wird der Text zu 18 kwietnia.
Einpacken
Der Umgang mit Datum und Uhrzeit ist nicht einfach. Wenn Sie jedoch die oben beschriebenen Standards befolgen und die richtigen Typen verwenden, können Sie große Fehler vermeiden.
Ich hoffe, dass mein Einblick in Datums- und Zeitrandfälle bei Ihren Projekten nützlich sein wird. Viel Glück!
Ursprünglich veröffentlicht unter https://www.thedroidsonroids.com am 26. April 2021.
Das obige ist der detaillierte Inhalt vonEdge Cases in der App- und Backend-Entwicklung – Termine und Zeiten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
