Am besten wär das ganze Jahr eine halbe Stunde vorstellen, zum glück läuft auf meinen geräten nur linux e co lg Martin Senoner
--- Ursprüngl. Mitteilung --- Von: hanstorggler@netscape.net Gesend.: 26.03.2013, 16:05 An: lugbz-list@lugbz.org Betreff: [Lugbz-list] Sommerzeit ?
Thomas Pircher tehpeh@gmx.net wrote:
Martin Senoner wrote:
Am besten wär das ganze Jahr eine halbe Stunde vorstellen,
Echte Männer™ stellen ihre Uhren auf UTC und schreiben das Offset darunter! ;-)
+1
lol
Patrick
Hoi TP :)
On 26/03/2013, Thomas Pircher tehpeh@gmx.net wrote:
Martin Senoner wrote:
Am besten wär das ganze Jahr eine halbe Stunde vorstellen,
Echte Männer™ stellen ihre Uhren auf UTC und schreiben das Offset darunter! ;-)
Phew, was fuer ein Amateurinformatiker!!! Echte Männer™ benutzen nur das Unix Time!
lol :D
mfg, Stefano
Chris Mair chris@1006.org schrieb:
Phew, was fuer ein Amateurinformatiker!!! Echte Männer™ benutzen nur das Unix Time!
Wir treffen uns January 19, 2038, at 03:14:08 UTC.
Machen wir dann variablenverlängerungsparty und hängen noch ein bit dran? :P
~markus
Bis dann :)
Bye, Chris.
Phew, was fuer ein Amateurinformatiker!!! Echte Männer™ benutzen nur das Unix Time!
Wir treffen uns January 19, 2038, at 03:14:08 UTC.
Machen wir dann variablenverlängerungsparty und hängen noch ein bit dran? :P
Aber immer nur ein einzelnes, wie die BIOS Programmierer. Sonst ist nicht lustig ;)
Bye, Chris.
Chris Mair wrote:
Aber immer nur ein einzelnes, wie die BIOS Programmierer. Sonst ist nicht lustig ;)
Ein Bit is mehr als genug! Das gibt uns weitrere 68 Jahre, bis dann sind wir alle in Rente (oder weiter) und das Problem ist dann sowieso ein SEP[1]!
Thomas
Wurden fie biosprogrammierer von m$ bezahlt?
Also ich wäre ja für eine sich selbst vergrößernde variable...so eine art datumsvariablenliste...keine ahnung wie eigentlich geplant ist die datumssache auf lange zeit zu lösen (sprich auf ewig). Wäre auch mal interessant zu wissen!
~markus
Thomas Pircher tehpeh@gmx.net schrieb:
Chris Mair wrote:
Aber immer nur ein einzelnes, wie die BIOS Programmierer. Sonst ist nicht lustig ;)
Ein Bit is mehr als genug! Das gibt uns weitrere 68 Jahre, bis dann sind wir alle in Rente (oder weiter) und das Problem ist dann sowieso ein SEP[1]!
Thomas
[1] http://en.wikipedia.org/wiki/Somebody_Else%27s_Problem _______________________________________________ http://lists.lugbz.org/cgi-bin/mailman/listinfo/lugbz-list
Also ich wäre ja für eine sich selbst vergrößernde variable...so eine art datumsvariablenliste...keine ahnung wie eigentlich geplant ist die datumssache auf lange zeit zu lösen (sprich auf ewig). Wäre auch mal interessant zu wissen!
Ganz einfach.
linuxA$ date -d "2039-01-01" +"%s" 2177449200
Erstes System verwendet einen 64 Bit Zaehler. Und 64bit == ewig ;)
Das sollte bei allen halbwegs neuen Linuxes so sein, sicher bei den 64-bittigen.
Hier habe ich ein altes, da siehts dann so aus:
linuxB$ date -d "2039-01-01" +"%s" date: invalid date `2039-01-01'
Bye, Chris.
Markus Windegger wrote:
Wurden fie biosprogrammierer von m$ bezahlt?
Wieso? MS wird ja vieles nachgesagt, aber Sparsamkeit mit Resourcen ist meines Erachtens nicht dabei... ;)
Also ich wäre ja für eine sich selbst vergrößernde variable...so eine
art
datumsvariablenliste...keine ahnung wie eigentlich geplant ist die datumssache auf lange zeit zu lösen (sprich auf ewig). Wäre auch mal interessant zu wissen!
http://en.wikipedia.org/wiki/Year_2038_problem#Solutions
Die verschiedenen Lösungsansätze sind: - time_t als unsigned (32 bit) definieren. Gibt uns Zeit bis 2106 (und dann: SEP). - time_t als 64 bit definieren, gibt uns Zeit bis 2,147,483,647 + Start. (Start kann 1970 sein, oder 1900 etc). - oder eine ganz neue Funktion zu definieren und time(2) als obsolet markieren.
"Sich selbst vergrößernde Variablen" sind im Datenaustausch sehr praktisch, zum Beispiel DER, BER und PER (http://en.wikipedia.org/wiki/X.690) aber als interne Variablen in einem Programm sind sie nicht geeignet. Zum Beispiel kannst du mit solchen Variablen nicht gut rechnen, und du weißt nicht im voraus, wie viel Spiecher du allokieren musst, wenn du die Zeit vom OS ausliest. Da ist es praktischer, eine Integer Variable zu verwenden, die "groß genug" ist.
Thomas
Ressourcensparend nicht, aber so muss man sich jedesmal einen neuen pc/rechner anschaffen, wenn ein bit neu dazukommt, und auf den meisten pc's ist nun mal m$ beim kauf drauf...
Ok...stimmt...mit dynamischen variablen ist das so ne sache...64-bit = ewigkeit ist schon ok, aber vom theoretischen standpunkt aus, wenn du programmcodes auf ihre sicherheit hin überprüfst, hast du sozusagen nur wahre aussagen mit einer bestimmten einschränkung und nicht eine "immer" wahre aussage...oder nicht?
Sry über diese komischen fragen, aber sowas ist eig recht interessant für mich :)
~markus
Thomas Pircher tehpeh@gmx.net schrieb:
Markus Windegger wrote:
Wurden fie biosprogrammierer von m$ bezahlt?
Wieso? MS wird ja vieles nachgesagt, aber Sparsamkeit mit Resourcen ist meines Erachtens nicht dabei... ;)
Also ich wäre ja für eine sich selbst vergrößernde variable...so eine
art
datumsvariablenliste...keine ahnung wie eigentlich geplant ist die datumssache auf lange zeit zu lösen (sprich auf ewig). Wäre auch mal interessant zu wissen!
http://en.wikipedia.org/wiki/Year_2038_problem#Solutions
Die verschiedenen Lösungsansätze sind:
- time_t als unsigned (32 bit) definieren. Gibt uns Zeit bis 2106 (und
dann: SEP).
- time_t als 64 bit definieren, gibt uns Zeit bis 2,147,483,647 +
Start. (Start kann 1970 sein, oder 1900 etc).
- oder eine ganz neue Funktion zu definieren und time(2) als obsolet
markieren.
"Sich selbst vergrößernde Variablen" sind im Datenaustausch sehr praktisch, zum Beispiel DER, BER und PER (http://en.wikipedia.org/wiki/X.690) aber als interne Variablen in einem Programm sind sie nicht geeignet. Zum Beispiel kannst du mit solchen Variablen nicht gut rechnen, und du weißt nicht im voraus, wie viel Spiecher du allokieren musst, wenn du die Zeit vom OS ausliest. Da ist es praktischer, eine Integer Variable zu verwenden, die "groß genug" ist.
Thomas _______________________________________________ http://lists.lugbz.org/cgi-bin/mailman/listinfo/lugbz-list
On Wed, 27 Mar 2013 12:19:35 +0100, Markus Windegger markus@mowiso.com wrote:
Ressourcensparend nicht, aber so muss man sich jedesmal einen neuen pc/rechner anschaffen, wenn ein bit neu dazukommt, und auf den meisten
pc's
ist nun mal m$ beim kauf drauf...
Auch wenn ein Bit dazugenommen wird (das heisst, man nimmt das Sign-Bit von time_t als Significantes Bit), dann steht der nächste Rechnerkauf nach dem Jahr 2100 an, was von deinen Kindern oder Enkeln doch zu verkraften sein sollte. ;)
Ich habe ehrlich gesagt keine Ahnung wie das aktuelle Datum in einem modernen BIOS gespeichert wird. Kann sein, dass es in UNIX time gespeichert wird, aber das ist ein Problem des Betriebssystems. Anwendungen bekommen die Zeit vom BS geliefert, da ist es irrelevant, wie das Datum im BIOS gespeichert wird. Moderne BS beziehen die Zeit in der Regel vom Netz (mttels NTP o.Ä) und verwenden die BIOS Uhrzeit nur, um eine halbwegs genaue Zeit nach dem Booten zu haben.
Ok...stimmt...mit dynamischen variablen ist das so ne sache...64-bit = ewigkeit ist schon ok, aber vom theoretischen standpunkt aus, wenn du programmcodes auf ihre sicherheit hin überprüfst, hast du sozusagen nur wahre aussagen mit einer bestimmten einschränkung und nicht eine "immer" wahre aussage...oder nicht?
Naja, überlass die immer wahren Aussagen getrost den Mathematikern, als Ingegneur hält man sich lieber and die Kunst des Möglichen, meiner Erfahrung nach.
Thomas
-
Chris Mair -
Markus Windegger -
Martin Senoner -
Patrick Ohnewein -
Steevie -
Thomas Pircher