PHP 8.6: Was SortDirection und TimeDuration verbessern
Aufsteigend oder absteigend. Fünf Sekunden oder fünftausend Millisekunden. Solche Angaben sind schnell geschrieben. Probleme entstehen, wenn mehrere Bibliotheken dafür unterschiedliche Darstellungen erwarten. PHP 8.6 soll mit SortDirection und TimeDuration zwei gemeinsame Typen für diese Aufgaben bekommen. Der praktische Gewinn liegt an den Schnittstellen: Code kann genauer ausdrücken, welche Bedeutung ein übergebener Wert hat.
Die allgemeine Verfügbarkeit von PHP 8.6 ist für den 19. November 2026 geplant. Beide Ergänzungen sind angenommen. Technisch lösen sie unterschiedliche Probleme. Ihr gemeinsamer Ansatz: Häufig benötigte Begriffe erhalten eine feste Darstellung in der Standardbibliothek.
SortDirection macht aus einer Vereinbarung einen Typ
SortDirection ist eine unbacked Enum im globalen Namensraum. Sie besitzt genau zwei Fälle: Ascending und Descending. „Unbacked“ bedeutet, dass hinter diesen Fällen kein fest zugeordneter String- oder Integer-Wert steht. Die Sortierrichtung wird durch den jeweiligen Enum-Fall ausgedrückt.
Eine Schnittstelle kann dadurch ausdrücklich SortDirection verlangen. Beim Aufruf steht dann etwa SortDirection::Ascending. Das ist lesbarer als eine Zahl, deren Bedeutung man erst nachschlagen muss. Auch ein frei gewählter Text muss nicht mehr als gemeinsame Konvention zwischen aufrufendem und aufgerufenem Code dienen.
Die technische Grenze ist wichtig: Die Enum beschreibt die Richtung. Sie legt weder den Sortieralgorithmus fest noch die Regeln, nach denen zwei Elemente verglichen werden. Ob beispielsweise Namen, Zeitpunkte oder andere Werte verglichen werden, bleibt Aufgabe der jeweiligen Implementierung. Ein sauberer Richtungstyp korrigiert keine fehlerhafte Vergleichslogik.
Ihr Nutzen entsteht dort, wo APIs denselben Typ verwenden. Zwei Bibliotheken müssen dann nicht jeweils eine eigene Darstellung für aufsteigend und absteigend definieren. Die Standardbibliothek liefert dafür ein gemeinsames Vokabular.
TimeDuration gibt einer Zeitspanne eine eindeutige Form
Bei Zeitangaben reicht ein Zahlenwert häufig nicht aus. Ein hypothetischer Parameter mit dem Wert 500 lässt offen, ob Sekunden oder Millisekunden gemeint sind. Das lässt sich dokumentieren. Ein eigener Typ kann diese Bedeutung aber direkt an der Schnittstelle festhalten.
TimeDuration ist eine final readonly Klasse im neuen Namensraum Time. Sie stellt Zeitdauern mit Nanosekunden-Genauigkeit dar. Fabrikmethoden wie fromSeconds() und fromMilliseconds() benennen bereits beim Erzeugen die verwendete Einheit. Der Unterschied zwischen Sekunden und Millisekunden bleibt damit im aufrufenden Code sichtbar.
Für Berechnungen stehen unter anderem add() und sub() sowie Vergleichsmethoden bereit. Die Zeitdauer bekommt dadurch eine eigene technische Form, statt bei jeder Weitergabe erneut als nackte Zahl interpretiert werden zu müssen. „Final“ verhindert das Ableiten weiterer Klassen; „readonly“ begrenzt nachträgliche Änderungen am Objektzustand.
Die Nanosekunden-Genauigkeit beschreibt dabei die Darstellung der Dauer. Daraus folgt keine Zusage, dass eine Anwendung ebenso genau warten, Aufgaben ausführen oder Zeit messen kann. Ein präziser Datentyp und das tatsächliche Zeitverhalten eines Systems sind verschiedene Dinge.
Kalender und verstrichene Zeit bleiben getrennte Aufgaben
Zur bisherigen Inkonsistenz bei der Zeitbehandlung gehört die Vermischung kalendarischer Intervalle mit verstrichenen Zeitspannen. Ein Monat ist eine Kalenderangabe. Eine fest definierte Anzahl Sekunden beschreibt eine Dauer. Wer beides gleich behandelt, macht aus unterschiedlichen Anforderungen scheinbar dieselbe Rechenaufgabe.
TimeDuration schafft für die Dauer einen ausdrücklichen Typ. Das hilft beim Entwurf einer API: Soll sie eine verstrichene Zeitspanne annehmen, kann sie genau das verlangen. Der Aufrufer muss die Bedeutung dann nicht aus einem Parameternamen oder einer beiläufigen Beschreibung erschließen.
Die Klasse nimmt Entwicklern allerdings keine fachliche Entscheidung ab. Vor der Wahl des Typs muss klar sein, ob eine Funktion eine Kalenderoperation oder eine Dauer benötigt. Ein präziser Typ schützt nur dann vor Missverständnissen, wenn er zum vorgesehenen Zweck passt.
Gemeinsame Typen brauchen passende Schnittstellen
Das Bereitstellen der Typen allein vereinheitlicht noch keine Anwendung. Eine API muss SortDirection oder TimeDuration ausdrücklich annehmen und verarbeiten. Wo eine Schnittstelle andere Darstellungen verlangt, bleibt eine Übersetzung nötig. Aus einem gemeinsamen Standard entsteht also nicht automatisch eine durchgehend gemeinsame Nutzung.
Für neue Schnittstellen liegt hier der konkrete Nutzen von PHP 8.6: Entwickler können zwei wiederkehrende Begriffe verwenden, ohne eigene Ersatztypen dafür entwerfen zu müssen. Bei bestehendem Code lohnt der Blick auf die Übergabepunkte zwischen Komponenten. Dort entscheidet sich, ob die neuen Typen Mehrdeutigkeit beseitigen oder zunächst nur einen zusätzlichen Konvertierungsschritt erzeugen.
