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 ---
Gesend.: 26.03.2013, 16:05
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! 
SCNR,
Thomas
Thomas Pircher <tehpeh(a)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 
Phew, was fuer ein Amateurinformatiker!!! Echte Männer™ benutzen nur
das Unix Time!
Wir treffen uns January 19, 2038, at 03:14:08 UTC.
Bis dann
Bye,
Chris.
Chris Mair <chris(a)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? 
~markus
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?
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(a)gmx.net> schrieb:
attachment.htm (1.41 KB)
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(a)gmx.net> schrieb:
attachment.htm (3.04 KB)
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