date()

[Tobias S.]

Hallo

Mein Problem ist folgendes. Ich will mit PHP den Wochentags anmen in Deutsch ausgeben, und zwar eine Woche im voraus.

Mit der Funktion date('w', strtotime('+1 days'))

habe ich es nicht geschafft.

lg

[Mathias Brodala]

Hallo Tobias.

Mein Problem ist folgendes. Ich will mit PHP den Wochentags anmen in Deutsch ausgeben, und zwar eine Woche im voraus.

Mit der Funktion date('w', strtotime('+1 days'))

habe ich es nicht geschafft.

An Stelle von date() möchtest du strftime() verwenden. Zusätzlich bedarf es zuvor noch eines Aufrufs von setlocale() für die deutsche Version der Wochentage.

Einen schönen Dienstag noch.

Gruß, Mathias

[rob]

Hi!

Zusätzlich bedarf es zuvor noch eines Aufrufs von setlocale() für die deutsche Version der Wochentage.

Naja, kommt ganz drauf an, welche Locale auf dem Server voreingestellt ist.
Aber zur Sicherheit würde ich die Funktion in jedem Fall vorher aufrufen. Zumindest LC_TIME sollte damit gesetzt werden.

strftime( "%A" ); // ausgeschriebener Name des Wochentages
strftime( "%a" ); // abegkürzter Name des Wochentages

Gruß,
rob

[Auge]

Hallo

Zusätzlich bedarf es zuvor noch eines Aufrufs von setlocale() für die deutsche Version der Wochentage.
Naja, kommt ganz drauf an, welche Locale auf dem Server voreingestellt ist.

Falls das nix bringt, weil die Locale nicht oder für den gewünschten Zweck falsch eingestellt ist, kann man sich auch mit einem Array der Wochentage behelfen. Da man sich den Wochentag auch numerisch ausgeben lasen kann, muss man dann nur noch mit dem ermittelten Wert das richtige Arrayelement auswählen.

# Beginn bei Sonntag, weil dies die von PHP verwendete Zaehlweise ist  
$wochentage = array(  
"Sonntag",  
"Montag",  
"Dienstag",  
"Mittwoch",  
"Donnerstag",  
"Freitag",  
"Samstag");  
  
# Ein fiktiver UNIX-Zeitstempel  
$timestamp = 1234567890;  
  
# Ausgabe des Wochentags (date("w") gibt einen Wert zwischen 0 (So) und 6 (Sa) zurueck)  
echo $wochentage[date("w",$timestamp)];

Tschö, Auge

[Tom]

Hello,

Beginn bei Sonntag, weil dies die von PHP verwendete Zaehlweise ist

$wochentage = array(
"Sonntag",
"Montag",
"Dienstag",
"Mittwoch",
"Donnerstag",
"Freitag",
"Samstag");

Ein fiktiver UNIX-Zeitstempel

$timestamp = 1234567890;

Ausgabe des Wochentags (date("w") gibt einen Wert zwischen 0 (So) und 6 (Sa) zurueck)

echo $wochentage[date("w",$timestamp)];

  
Was gibt denn date('w') bei einem Timestamp, der zu groß oder negativ ist?  
Das habe ich vergessen...  
  
  
  
Harzliche Grüße vom Berg  
<http://www.annerschbarrich.de>  
  
Tom

-- 
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen  
Nur selber lernen macht schlau  
![](http://bitworks.de/~selfHTML/Virencheck.gif)  

[rob]

Hi!

Was gibt denn date('w') bei einem Timestamp, der zu groß oder negativ ist?
Das habe ich vergessen...

Gerade mal getestet. Allerdings nur auf Windows.

Mit negativem Timestamp:
<?php echo date( "l dS of F Y h:i:s A", -1 ); ?>

erhalte ich eine Fehlermeldung:
Warning: date() [function.date.html]: Windows does not support dates prior to midnight (00:00:00), January 1, 1970 in C:\server\www\test1.php on line 2

Was auf meinem Linux-System passiert, kann ich jetzt nicht sagen. Das müßte ich aber auch noch mal probieren...

Mit einem zu großen Timestamp:
<?php echo date( "l dS of F Y h:i:s A", 999999999999999999999999999999999999 );?>

erhalte ich:
Thursday 01st of January 1970 01:00:00 AM

Hat also scheinbar den gleichen Effekt, wie wenn ich den Timestamp 0 verwende.

Schöner Gruß und gute Nacht,
rob

[Christian Seiler]

Hallo Tom,

Was gibt denn date('w') bei einem Timestamp, der zu groß oder negativ ist?
Das habe ich vergessen...

Negative Timestamps:
   - Windows: funktionieren nicht
   - Andere Betriebsysteme: Bis zur Integer-Grenze runter (irgendwann im
     Jahr 1901 für 32-bit-Systeme) funktioniert's problemlos.

Betragsmäßig zu große Timestamps: Die kriegt man in PHP gar nicht erst in eine Integer-Variable - und deswegen braucht man auch gar nicht darüber spekulieren, was eine Funktion ausspucken würde, die eine Integer-Variable erwartet.

Wenn man portabel Wochentage für Daten kleiner als 1970 berechnen will (naja, und für > 2038, aber ehrlich gesagt leuchtet mir nicht ein, warum man das tun sollte ;-)), dann muss man das selbst tun. Am einfachsten wandelt man das Datum in eine Julianische Tageszahl um und berechnet dann den Modulo zu 7 - dann erhält man den Wochentag:

// $g: Ob der gregorianische oder julianische Kalender  
// verwendet werden soll; vor dem 15.10.1582 GC (5.10.1582 JC)  
// wurde nur der julianische Kalender verwendet, danach  
// hängt die Verwendung des Kalenders von der Lokalität ab  
// (Griechenland hat erst Anfang des 20. Jhdts. auf GC umgestellt)  
function wochentag ($jahr, $monat, $tag, $g = true) {  
 static $wochentage = array (  
  'Montag',  
  'Dienstag',  
  'Mittwoch',  
  'Donnerstag',  
  'Freitag',  
  'Samstag',  
  'Sonntag'  
 );  
  
 // Das Jahr fängt im März an, dann lassen sich die  
 // Monatsanfänge per linearer Regression an eine Gerade  
 // anpassen.  
 if ($monat <= 2) {  
  $jahr--;  
  $monat += 12;  
 }  
  
 if ($g) {  
  // korrektur für den gregorianischen Kalender:  
  // Die Schaltjahresregel ist hier eine andere, deswegen  
  // muss ein Korrekturterm hinzugefügt werden  
  $jahrhundert = floor ($jahr / 100);  
  $korrektur = 2 - $jahrhundert + floor ($jahrhundert / 4);  
 } else {  
  $korrektur = 0;  
 }  
 // die julianische tageszahl ist definiert als die anzahl an  
 // tage seit Montag, 1. Januar 4713 v.u.Z. JC (d.h. $jahr == -4712)  
 // Wenn wir also 4716 Jahre darauf addieren, dann erhalten wir  
 // 4 Jahre zuveil (dafür macht uns floor() keine Probleme), die  
 // 4 Jahre (1461 Tage) müssen wir später aber wieder abziehen  
 $jul_tag_zahl = floor (365.25 * ($jahr + 4716));  
  
 // Monatsanteil: Wir gehen davon aus, dass das Jahr im März beginnt,  
 // die Folge floor (30.6001 * ($monat + 1)) - 122 ergibt gerade die  
 // korrekten Offsets für die Monate (0 für März, 31 für April, 61 für  
 // Mai, etc.) - die -122 werden später berücksichtigt  
 $jul_tag_zahl += floor (30.6001 * ($monat + 1));  
  
 // Den Tag addieren wir einfach darauf - allerdings müssen wir  
 // später 1 abziehen, da der Tag 1 ja den Abstand 0 haben soll  
 $jul_tag_zahl += $tag;  
  
 // Die Korrektur für den gregorianischen Kalender muss berücksichtigt  
 // werden.  
 $jul_tag_zahl += $korrektur;  
  
 // Nun wird noch der feste Offset von obigen Rechnungen berücksichtigt:  
 // 1461 Tage zuviel von der Jahresberechnung  
 // 122 Tage zuviel von der Monatsberechnung  
 // 60 Tage zuwenig, weil das Jahr eben nicht im März anfängt  
 //                  (4713 v.u.Z. war ein Schaltjahr)  
 // 1 Tag zuviel von der Tageszahl  
 // = 1524 Tage zuviel  
 $jul_tag_zahl -= 1524;  
  
 // 1.1.4713 v.u.Z. JC war ein Montag hätte $jul_tag_zahl 0, d.h.  
 // $jul_tag_zahl % 7 ergibt den Wochentag mit 0 als Montag  
 return $wochentage[$jul_tag_zahl % 7];  
}

Wenn man dann andere Berechnungen anstellen will, wie z.B. die Anzahl der Tage zwischen zwei Daten, dann kann man beide Daten einfach in eine Julianische Tageszahl umwandeln und die dann voneinander abziehen.

Viele Grüße,
Christian

[Tom]

Hello Christian,

Danke.
Diesen ausführlichen Excurs habe ich mir gleich in meine Programmiersammlung unter "Datum" abgelegt.
Ich weiß zwar nicht, ob ich 2038 noch schaffe, aber die Hoffnung stirbt zuletzt :-)

Ob es da eine ähnlich große Hysterie geben wird, wie mit dem Jahr 2000?
Spannende Frage, welches Betriebssystem sich bis dahin durchgesetzt haben wird.
Wahrscheinlich wäre die frühzeitige Behebung des Problems im OS und seinen Helferlein (übliche Software) ein ausschlaggebendes Argument für die Entscheidung?

Da das Problem ja kein Hardware-Problem ist, wird es auch schon ca. 2018 anfangen zu tragen. Verträge über 20 Jahre Laufzeit sind schließlich durchaus üblich. Wäre schon schlecht, wenn man da dann bestimmte Berechnungen und Planungen nicht mehr anstellen könnte...
OK, das betrifft nur einige Sprachen.

Wie sieht es denn da bei den üblichen Tabellenkalkulationen aus? Können die "beliebig weit" voraussehen?

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Christian Seiler]

Hallo Tom,

Ob es da eine ähnlich große Hysterie geben wird, wie mit dem Jahr 2000?
Spannende Frage, welches Betriebssystem sich bis dahin durchgesetzt haben wird.

Ich weiß nicht wie's mit Windows aussieht (gehe aber mal davon aus, dass es da ähnlich ist), aber unter Linux, FreeBSD, Mac OS X etc. haben bereits jetzt schon keine Probleme mehr mit dem Jahr 2038 - wenn sie auf einer 64bit-Architektur laufen. Bis Deinem angegebenen Datum von 2018 dürften 64bit-Prozessoren die Regel sein (oder evtl. gibt's da schon 128bit? ;-)) - daher löst sich das Jahr 2038-Problem bis es relevant würde von selbst auf. Ich mache mir da eigentlich keinerlei Sorgen.

Viele Grüße,
Christian