Zend_Date API ÜbersichtObwohl die API von Zend_Date simpel und einheitlich ist, ist dessen Design aufgrund der reichhaltigen Permutationen von Operationen und Operanden flexibel und mächtig. Zend_Date OptionenAuswahl der Art des DatumsformatsViele Methoden benutzen Zeichenketten für Datumsformate so ähnlich wie date() von PHP. Wenn man mit den Zeichen der Datumsformaten von PHP mehr Erfahrung hat als mit den ISO-Zeichen für Formate, dann kann man Zend_Date::setOptions(array('format_type' => 'php')) benutzen. Danach können die Zeichen von PHP für Datumsformate für alle Funktionen verwendet werden, die einen $format-Parameter akzeptieren. Durch Benutzen von Zend_Date::setOptions(array('format_type' => 'iso')) kann man wieder auf den Standardmodus zurückwechseln, der nur ISO-Zeichen für Datumsformate unterstützt. Für eine Liste von unterstützten Zeichencodes kann hier nachgelesen werden: selbst definierte AUSGABE-Formate bei Verwendung der date()-Formatzeichen von PHP Sommer-/Winterzeit und DatumsberechnungenWenn Daten manipuliert werden, überschreiten sie manchmal die DST-Grenze (Sommer-/Winterzeit), was normalerweise dazu führt, dass das Datum eine Stunde verliert oder hinzubekommt. Wenn zum Beispiel ein Monat zu einem Datum vor einer DST-Änderung hinzugefügt wird und der Ergebnismonat nach dieser Änderung liegt, sieht es so aus, als ob das Datum durch den Wert des geänderten Datums eine Stunde verliert oder hinzubekommt. Für Grenzstunden wie Mitternacht, für den ersten oder letzten Tag eines Monats, führt das Hinzufügen von genügend Monaten dazu, dass das Datum eine Stunde verliert, wenn die DST-Grenze überschritten wird und damit zum letzten Tag des Vormonats wird, was den Anschein eines "eins fehlt" Fehlers erweckt. Um diese Situationen zu vermeiden, kann die DST-Änderung durch Verwendung der Option fix_dst ignoriert werden. Wenn eine DST-Grenze überschritten wird, wird ja normalerweise abhängig vom Datum eine Stunde hinzugefügt oder entfernt. Zum Beispiel führt eine Datumsberechnung mit DST im Frühling zu einem Datum, welche einen Tag weniger hat als erwartet, wenn die Zeit des Originaldatums 00:00:00 war. Da Zend_Date auf Zeitstempeln basiert und nicht auf Kalenderdaten mit Zeitkomponenten, verliert der Zeitstempel eine Stunde, was zu einem Datum führt, das einen Kalendertag weniger hat, als erwartet. Um solche Problem zu verhindern, kann die Option fix_dst verwendet werden, welche standardmäßig TRUE ist. Das führt dazu, dass die DST keinen Einfluss mehr bei Datumsberechnungen hat ( addMonth(), subMonth()). Zend_Date::setOptions(array('fix_dst' => false)) kann benutzt werden, um Hinzufügen oder Entfernen der DST-Anpassung zu gestatten, wenn Datumsberechnungen durchgeführt werden. Wenn die aktuelle Zeitzone innerhalb der Instanz von Zend_Date auf UTC oder GMT gestellt ist, wird die Option 'fix_dst' nicht verwendet, weil diese zwei Zeitzonen nicht mit DST arbeiten. Wenn die Zeitzone für diese Instanz wieder auf eine Zeitzone gestellt wird, die nicht UTC oder GMT ist, wird die vorher definierte Option 'fix_dst' wieder für die Datumsberechnungen verwendet. MonatsberechnungenWenn Monate zu einem existierenden Datum hinzugefügt oder davon entfernt werden, kann der Ergebniswert des Monatstages unerwartet sein, wenn das Originaldatum auf einen Tag gefallen ist, der Nahe am Ende des Monats ist. Wenn zum Beispiel ein Monat zum 31sten Jänner hinzugefügt wird, werden Personen, welche mit SQL vertraut sind, den 28sten Februar als Ergebnis erwarten. Auf der anderen Seite werden Personen, welche mit Excel und OpenOffice vertraut sind, den 3ten März als Ergebnis erwarten. Das Problem besteht nur, wenn der Ergebnismonat den Tag nicht hat, der im Originaldatum gesetzt war. Zend Framework Entwickler können das gewünschte Verhalten beeinflussen, indem die Option extend_month genutzt wird, die bei einem Wert von FALSE das SQL-Verhalten, oder bei einem Wert von TRUE das Tabellenverhalten auswählt. Das Standardverhalten für extend_month ist FALSE, um SQL-kompatibles Verhalten zu erlauben. Zend_Date führt Monatsberechnungen standardmäßig in der Art durch, dass Daten auf das Monatsende hin abgeschnitten werden (wenn notwendig), ohne dass in den nächsten Monat umgebrochen wird, wenn das Originaldatum einen Monatstag bestimmt, der die Anzahl der Tage des Ergebnismonats überschreitet. Zend_Date::setOptions(array('extend_month' => true)) kann benutzt werden, um Monatsberechnungen wie in populären Tabellenkalkulationen durchzuführen. Lokalisierung und Normalisierung von Daten mit Zend_Cache schneller machenMan kann Zend_Date schneller machen, indem ein Zend_Cache-Adapter verwendet wird. Das verschnellert alle Methoden von Zend_Date, wenn lokalisierte Daten verwendet werden. Zum Beispiel werden alle Methoden hiervon profitieren, welche Zend_Date::DATE und Zend_Date::TIME Konstanten akzeptieren. Um einen Zend_Cache-Adapter für Zend_Date zu verwenden, muss nur Zend_Date::setOptions(array('cache' => $adapter)) aufgerufen werden. Syncronisierte Zeiten mit Zend_TimeSync erhaltenNormalerweise unterscheiden sich die Uhren von Servern und Computern voneinander. Zend_Date ist dazu fähig, solche Probleme mit Hilfe von Zend_TimeSync zu handhaben. Mit Zend_Date::setOptions(array('timesync' => $timeserver)) kann ein Zeitserver gesetzt werden, welcher den Unterschied zwischen dem eigenen aktuellen Zeitstempel und dem wirklichen aktuellen Zeitstempel für alle Instanzen von Zend_Date setzt. Die Verwendung dieser Option ändert nicht den Zeitstempel von bestehenden Instanzen. Am besten ist es also, dies innerhalb der Bootstrap-Datei zu setzen. Arbeiten mit DatumswertenSobald die Eingabe durch die Erstellung eines Zend_Date-Objekts normalisiert wurde, hat es eine zugeordnete Zeitzone aber die interne Darstellung verwendet » UNIX-Zeitstempel. Damit ein Datum in einer lokalisierten Art und Weise durchsucht werden kann, muss zuerst eine Zeitzone bekannt sein. Die Standardzeitzone ist immer GMT oder UTC. Um die Zeitzone des Objekts zu inspizieren, kann getTimeZone() verwendet werden. Um die Zeitzone des Objekts zu wechseln, kann setTimeZone() verwendet werden. Alle Änderungen des Objekts sind immer relativ zu seiner Zeitzone zu sehen. Man sollte es vermeiden, Teile von Datumsobjekten mit unterschiedlichen Zeitzonen zu mischen oder zu vergleichen, da dies grundsätzlich unerwartete Resultate zeigen kann, es sei denn, die Manipulationen beziehen sich nur auf den [UNIX-]Zeitstempel. Das Arbeiten mit Zend_Date-Objekten, die unterschiedliche Zeitzonen haben, funktioniert grundsätzlich, abgesehen davon wie vorher erwähnt, da Daten bei der Instantiierung von Zend_Date zu UNIX-Zeitstempel normalisiert werden. Die meisten Methoden erwarten eine Konstante für die Auswahl des gewünschten Teils $part des Datums, wie z.B. Zend_Date::HOUR. Diese Konstanten sind für alle unten angeführten Funktionen gültig. Eine Liste aller vorhandenen Konstanten wird hier beschrieben: Liste aller Konstanten. Wenn $part nicht spezifiziert wird, wird Zend_Date::TIMESTAMP angenommen. Alternativ kann ein benutzerdefiniertes Format für $part verwendet werden, mit Hilfe der gleichen Mechanismen und Formatdefinitionen wie bei Zend_Locale_Format::getDate(). Wenn ein Datumsobjekt durch Verwendung eines offensichtlich falschen Datums erstellt wird (z.B. wenn die Nummer des Monats größer als 12 ist), wird Zend_Date eine Ausnahme werfen, solange kein spezielles Datumsformat ausgewählt wurde, das heißt, $part ist entweder NULL oder Zend_Date::DATES (ein "fehlertolerantes" Format). Example #1 Benutzerdefinierte Eingabeformate für Daten
Wenn der optionale Parameter $locale angegeben wird, dann macht $locale den $date-Operand durch Ersetzen der Monatsnamen und Wochentagsnamen für die Zeichenkette $date eindeutig und sogar Datumszeichenketten können gemäß den Konventionen dieses Gebietsschemas analysiert werden (siehe Zend_Locale_Format::getDate()). Die automatische Normalisierung von lokalisierten $date-Angaben einer Zeichenkette werden nur dann durchgeführt wenn für $part eine der Konstanten Zend_Date::DATE* oder Zend_Date::TIME* verwendet wird. Das Gebietsschema identifiziert die Sprache, welche verwendet werden soll, um Monatsnamen und Wochentagsnamen zu analysieren, wenn $date eine Zeichenkette ist, die ein Datum enthält. Wenn der Eingabeparameter $date nicht angegeben wurde, dann definiert der Parameter $locale das Gebietsschema für lokalisierte Ausgaben (z.B. das Datumsformat für eine Ausgabe als Zeichenkette). Anzumerken ist auch, dass der Parameter $date stattdessen ein Typname sein kann (z.B. $hour für addHour()) wobei das nicht verhindert, dass ein Zend_Date Objekt als Argument für diesen Parameter angegeben werden kann. Wenn $locale nicht angegeben wurde, wird das Gebietsschema des aktuellen Objekts genommen, um $date zu interpretieren oder das lokalisierte Format für die Ausgabe auszuwählen. Seit Zend Framework 1.7.0 unterstützt Zend_Date auch die Verwendung eines anwendungsweiten Gebietsschemas. Man kann ganz einfach eine Zend_Locale-Instanz in der Registry setzen wie hier gezeigt. Mit dieser Schreibweise braucht man sich nicht um das manuelle Setzen eines Gebietsschemas für jede Instanz zu kümmern, wenn man dasselbe Gebietsschema mehrere Male verwenden will.
Grundsätzliche Zend_Date Operationen für die meisten Teile von DatenDie Methoden add(), sub(), compare(), get() und set() arbeiten generell mit Daten. In jedem Fall wird die Operation auf dem Datum durchgeführt, das in der Objektinstanz vorhanden ist. Der $date Operand wird für alle diese Methoden benötigt, außer für get() und kann eine Zend_Date Objektinstanz, eine numerische Zeichenkette oder ein Integer sein. Diese Methoden nehmen an, dass $date ein Zeitstempel ist, wenn es kein Objekt ist. Trotzdem kontrolliert der $part Operand, an welchem logischen Teil der zwei Daten gearbeitet werden soll, was Arbeiten an Teilen von Daten des Objekts erlaubt, wie Jahr oder Minute, selbst wenn $date eine lange Form einer Datumszeichenkette enthält wie "Dezember 31, 2007 23:59:59". Das Ergebnis der Operation ändert das Datum im Objekt außer bei compare() und get(). Example #2 Arbeiten an Teilen von Daten
Es existieren Komfortmethoden für jede Kombination von Grundoperationen und viele normale Datumsabschnitte wie in der unten stehenden Tabelle gezeigt. Diese Komfortmethoden erlauben uns faulen Programmierern zu vermeiden, dass die Konstanten für Datumsabschnitte ausgeschrieben werden müssen. Bequemerweise sind sie benannt durch Kombination eines Prefixes (Name der Basisoperation) und einem Suffix (Art des Datumsabschnittes), wie addYear(). In der unten stehenden Liste existieren alle Kombinationen von "Datumsabschnitten" und "Basisoperationen". Zum Beispiel die Operation "add" existiert für jeden dieser Datumsabschnitte wie addDay(), addYear() und viele mehr. Diese Komfortmethoden haben eine gleichwertige Funktionalität wie die Methoden für die Basisoperationen, aber sie erwarten $date-Operanden vom Typ Zeichenkette oder Integer, welche nur die Werte enthalten, die durch den Typ definiert sind, der durch das Suffix der Methode definiert wurde. Deshalb identifizieren diese Methoden (z.B. "Year" oder "Minute") die Einheit des $date Operanden, wenn $date eine Zeichenkette oder ein Integer ist Liste der Datumsabschnitte
Liste der Datums-OperationenDie unten aufgeführten Basisoperationen können statt den Komfortoperationen für spezielle Datumsabschnitte verwendet werden, wenn die entsprechenden Konstanten für den Parameter $part verwendet werden.
Vergleichen von DatenDie folgenden Basisoperationen haben keine vergleichbaren vereinfachten Methoden für Datumsabschnitt wie beschrieben unter Zend_Date API Overview.
Daten und Teile von Daten abfragenMehrere Methoden erlauben es, Werte abzurufen, die sich auf eine Zend_Date-Instanz beziehen.
Arbeiten mit SekundenbruchteilenViele Methoden unterstützen es, Werte relativ zu einer Zend_Date Instanz zu erhalten.
Sonnenaufgang / SonnenuntergangDrei Methoden geben Zugriff auf geographisch lokalisierte Informationen über die Sonne, was die Zeit für Sonnenaufgang und Sonnenuntergang beinhaltet.
|