localtime fehler oder "Das Ende der Welt"

[Wasser]

Hallo Forumer und Forumerinnen,

es ist schon eine ganze Zeit lang her, als ich regelmäßig hier im Forum war. Aber ich stehe mal wieder vor einem Problem und da viel mir das gute alte selfhtml-Forum ein....

Beim rumspielen mit localtime viel mir auf, dass die Funktion bei manchen in der Zukunft liegenden Werten Sekunden das Jahr 1970 ausspuckte.
Ich bin mir sicher, dass das bekannt ist, habe aber hier nicht finden können.

Ich hab das Musterscript (von selfhtml) mal schnell in ne Schleife gepackt und musste sehen, das ende der Zeitrechnung ist bereits 2037 erreicht ist, besser gesagt, wir fallen dan in das Jahr 1902 um von dort an, bis ins Jahr 1970 zu leben und im Jahr 1970 werden wir dann hängenbleiben.

Gibt es bereits eine neuere Funktion, die etwas zukunftssicherer ist, oder mache ich da irgendwo einen systematischen Fehler?

Ich hab das Schleifenscript mal unten angehängt.
das Ergebnis des Scriptes könnt Ihr Euch für kurze Zeit unter:
http://www.wasser.de/telefon-alt/forum/test.pl ansehen.
Danke für Eure Hilfe!

Gruß Wilm T. Klaas (alias Wasser)

---------------------------------------
#!/usr/bin/perl -w

use strict;
use CGI::Carp qw(fatalsToBrowser);

print "Content-type: text/html\n\n";

my $i = 1;

while ($i <= 1000){
        #jaja, das stimmt nicht 100% sollte aber zum testen reichen
 my $gtime = $i * 3600 * 24 * 365;

my ($Sekunden, $Minuten, $Stunden, $Monatstag, $Monat,
     $Jahr, $Wochentag, $Jahrestag, $Sommerzeit) = localtime($gtime);
 my $CTIME_String = localtime($gtime);
 $Monat+=1;
 $Jahrestag+=1;
 $Monat = $Monat < 10 ? $Monat = "0".$Monat : $Monat;
 $Monatstag = $Monatstag < 10 ? $Monatstag = "0".$Monatstag : $Monatstag;
 $Stunden = $Stunden < 10 ? $Stunden = "0".$Stunden : $Stunden;
 $Minuten = $Minuten < 10 ? $Minuten = "0".$Minuten : $Minuten;
 $Sekunden = $Sekunden < 10 ? $Sekunden = "0".$Sekunden : $Sekunden;
 $Jahr+=1900;
 my @Wochentage = ("Sonntag","Montag","Dienstag","Mittwoch","Donnerstag","Freitag","Samstag");
 my @Monatsnamen = ("","Januar","Februar","M&auml;rz","April","Mai","Juni",
           "Juli","August","September","Oktober","November","Dezember");

print "$Jahr<br>\n";

$i++;
 }

[Helmut Weber]

Hallo Wilm,

Die Unixzeit, die durch localtime ermittelt wird, wird sehr gut in Wikipedia beschrieben:
http://de.wikipedia.org/wiki/Unix-Zeit

Das daraus resultierende Jahr-2038-Problem wird ebenfalls in Wikipedia beschrieben:
http://de.wikipedia.org/wiki/Jahr-2038-Problem

Der Beste Satz daraus:
Technisch betrachtet "behebt" die 64-Bit-Umstellung das Jahr-2038-Problem auch nicht, sie verschiebt es nur etwa 290 Milliarden Jahre in die Zukunft. Das absehbare Jahr-292.471.208.678-Problem wird allerdings in Fachkreisen nicht als dringlich angesehen.

Herzliche Grüße aus Weinsberg
Helmut Weber

[Wasser]

Hallo Helmut,

und danke für Deine schnelle Antwort.
Ich kann nicht glauben, das es noch keine Ersatzfunktion dafür gibt...
Ich kann doch auch mit perl in einem Größeren Zahlenfeld als 4294967296 rechnen.
Die entwicklung des Datums folgt festen Mathematischen gesetzen, warum also sollte man mit 32 bit nicht weiter rechnen können?

________________________________________
#!/usr/bin/perl -w

use strict;
use CGI::Carp qw(fatalsToBrowser);

print "Content-type: text/html\n\n";

my $test = 4294967296;
my $teste = $test + 10000;
print "$test  + 10000 = $teste";
________________________________________

Mehr brauch ich doch nicht, oder?

Gruß Wilm t. Klaas (alias Wasser)

[Cheatah]

Hi,

Ich kann doch auch mit perl in einem Größeren Zahlenfeld als 4294967296 rechnen.

Perl könnte die Mathematik erfunden haben, dadurch würde das Betriebssystem immer noch keinen anderen Wert für die Zeit liefern. Und dummerweise bezieht sich Perl bei derlei Dingen auf das System, das sowas schließlich schon implementiert haben muss.

Die entwicklung des Datums folgt festen Mathematischen gesetzen,

Nun ja, im Jahre 3320 stimmt der Gregorianische Kalender schon wieder nicht. Aber Du hast insofern Recht, als man dieses Datum errechnen kann :-)

warum also sollte man mit 32 bit nicht weiter rechnen können?

Kann man. Das System muss es aber auch hergeben.

Cheatah

[wahsaga]

hi,

Nun ja, im Jahre 3320 stimmt der Gregorianische Kalender schon wieder nicht.

Das heißt, für welchen Tag genau sollte man da lieber keine wichtigen Termine vereinbaren ...?

gruß,
wahsaga

[Cheatah]

Hi,

Nun ja, im Jahre 3320 stimmt der Gregorianische Kalender schon wieder nicht.
Das heißt, für welchen Tag genau sollte man da lieber keine wichtigen Termine vereinbaren ...?

_das_ wiederum lässt sich nicht so genau sagen. Bei der letzten Korrektur wurden ganze zehn Tage ausgeglichen - wenn diese Menge repräsentativ ist, dürften sich Terminprobleme erst im Jahr 18962 (oder so) ergeben. Insofern muss ich Dich leider ein wenig im Unsicheren lassen. Ich verspreche aber, Dich rechtzeitig zu informieren, wenn ich etwas Genaueres erfahre.

Cheatah

[Wasser]

Hi,

Perl könnte die Mathematik erfunden haben, dadurch würde das Betriebssystem immer noch keinen anderen Wert für die Zeit liefern. Und dummerweise bezieht sich Perl bei derlei Dingen auf das System, das sowas schließlich schon implementiert haben muss.

Ich glaub, ich hab mich da nicht richtig ausgedückt, es geht mir nicht darum, elcher Sekundenwert vom System kommt, sondern darum, das der localtime nicht einmal mit größeren werten klar kommt, wenn man ihn diese liefert.

Aber ich befürchte, ich muß mir da selber was zurechtstricken.
z.B.
Sekunden mit "modulo 60" etc.
Wochentag durch "modulo (3600 * 24 * 7)" dann mit "(3600 * 24 * x) < >"

Nun ja, im Jahre 3320 stimmt der Gregorianische Kalender schon wieder nicht. Aber Du hast insofern Recht, als man dieses Datum errechnen kann :-)

Das reicht mir als Raum für einen "blick nach vorne".

warum also sollte man mit 32 bit nicht weiter rechnen können?
Kann man. Das System muss es aber auch hergeben.

...Ja, wenn das System die Sekunden ab 1970 liefert, angenommen ich habe eine hardware Uhr, welche mir die Sekunden in eine Textdatei schreibt, oder einfach im System mehr als die 32 Bit belegt werden..

Gruß Wilm

[Cheatah]

Hi,

Ich glaub, ich hab mich da nicht richtig ausgedückt, es geht mir nicht darum, elcher Sekundenwert vom System kommt, sondern darum, das der localtime nicht einmal mit größeren werten klar kommt, wenn man ihn diese liefert.

die Funktion localtime wird an das Betriebssystem delegiert. Kommt dieses mit höheren Werten klar, liefert auch Perl das richtige Ergebnis.

Nun ja, im Jahre 3320 stimmt der Gregorianische Kalender schon wieder nicht. Aber Du hast insofern Recht, als man dieses Datum errechnen kann :-)
Das reicht mir als Raum für einen "blick nach vorne".

Ach, immer diese Kleingeistigen, die nicht bereit sind, über den Tellerrand zu blicken ;-)

Cheatah

[wahsaga]

hi,

Beim rumspielen mit localtime viel mir auf, dass die Funktion bei manchen in der Zukunft liegenden Werten Sekunden das Jahr 1970 ausspuckte.
Ich bin mir sicher, dass das bekannt ist, habe aber hier nicht finden können.

tja, das liegt daran, dass die obere grenze eines signed integer mit 16 bit, also ein double word, bei 2.147.483.647 liegt.
tja, und 1.1.1970, 0 uhr plus 2.147.483.647 sekunden - kommt irgendwo im jahre 2037 aus.

Ich hab das Musterscript (von selfhtml) mal schnell in ne Schleife gepackt und musste sehen, das ende der Zeitrechnung ist bereits 2037 erreicht ist, besser gesagt, wir fallen dan in das Jahr 1902 um von dort an, bis ins Jahr 1970 zu leben und im Jahr 1970 werden wir dann hängenbleiben.

tja, zurück nach 1902 geht's dann, weil wir uns da an der negativen untergrenze des double word integers befinden - 1.1.1970 plus -2.147.483.648 sekunden.

Gibt es bereits eine neuere Funktion, die etwas zukunftssicherer ist, oder mache ich da irgendwo einen systematischen Fehler?

umstellung auf 64 bit integer, quad word, löst das problem erst mal auf ziemlich lange sicht ...

aber so lange das nicht alle systeme verwenden, endet die (EDV-)zukunft erst mal im jahre 2037.
mir wurscht - das sind beispielsweise immer noch um die 32 selftreffen bis da hin ...

gruß,
wahsaga

[Cheatah]

Hi,

Beim rumspielen mit localtime viel mir auf, dass die Funktion bei manchen in der Zukunft liegenden Werten Sekunden das Jahr 1970 ausspuckte.
Ich bin mir sicher, dass das bekannt ist, habe aber hier nicht finden können.

ja, das ist altbekannt. Die IETF hat auch bereits für die Zukunft vorgesorgt.

Ich hab das Musterscript (von selfhtml) mal schnell in ne Schleife gepackt und musste sehen, das ende der Zeitrechnung ist bereits 2037 erreicht ist,

Wenn die Menge der Sekunden seit dem 1.1.1970 2^31-1 erreicht hat, sofern ich gerade nicht mit den Potenzen durcheinander gekommen bin.

Gibt es bereits eine neuere Funktion, die etwas zukunftssicherer ist,

Ja, beispielsweise Time::Local::Extended

Cheatah

[Wasser]

Hi Cheatah,

schön Deinen Namen mal wieder zu lesen! :-)

Ja, beispielsweise Time::Local::Extended

Und Danke! Ich vermute genau das habe ich vergeblich gesucht.

Gruß Wasser

[Wasser]

Sorry, bin wohl etwas rappelig!

Ja, beispielsweise Time::Local::Extended

Ich vermute genau das habe ich vergeblich gesucht.

Und beim zweiten Blick, sehe ich, das das doch nur wieder ne Verschiebung um ein paar Jahre ist...

Und dabei wollte ich "nur mal eben" das Jahr 2100 in unixzeit ablegen :-(

Dennoch Danke und grüß mir mal bitte die anderen alten Hasen hier aus dem Forum

Wasser

[Cheatah]

Hi,

schön Deinen Namen mal wieder zu lesen! :-)

selbiges desgleichen :-) (Rest siehe anderes Posting.)

Cheatah

[Struppi]

Gibt es bereits eine neuere Funktion, die etwas zukunftssicherer ist, oder mache ich da irgendwo einen systematischen Fehler?

Wenn du nur Funktionen suchst um mit dem Datum zu rechnen kannst du mit Modulen arbeiten.
http://search.cpan.org/~stbey/Date-Calc-5.4/Calc.pod
oder
http://search.cpan.org/author/SBECK/DateManip-5.44/Manip.pod

Struppi.