Rok w asm

Loading thread data ...

a dlaczemu 2107? To jakaś magiczna data?

2107 to 83Bh, 2108 to 83Ch. Problem zaczyna sie dopiero od 65535, ale do tego czasu 16 bitowe procesory chyba beda historia.

Waldek

Reply to
Waldemar Krzok

Czaq pisze:

No kurcze chyba to proste, bez specjalnego pakowania dzień zajmie 0-32 więc 5 bitów miesiąc 0-16 wiec 4 bity na lata zostaje Ci 7 bitów i jak ci nie zależy na długowieczności masz te 128 lat jak w banku. pozdr Ak

Reply to
Andrzej Kmicic

A zdob to sobie jak chcesz. Myslisz, ze sa jakies odgorne wytyczne?

Dlatego, ze w starych systemach Microsoftu zapisywalo sie tylko parzyste sekundy, czyli rozdzielczosc wynosila 2s, co pozwalalo na zaoszczedzenie jednego bita. BTW, rozrozniasz bity od bajtow?

Nic, to jest ograniczenie stosowanego formatu zapisu. Jak ci to nie pasuje to zapisuj po swojemu, w czym problem?

Reply to
T.M.F.

Trzeba bylo od poczatku mowic, ze chodzi ci o zapis daty i czasu w FAT. Tam jest ograniczenie rozdzielczosci czasu do 2s, wlasnie po to, zeby czas dalo sie zapisac na 16-bitach. Gdybys chcial miec co do sekundy to trzebaby poswiecic dodatkowy bit, co w tym przypadku przeklada sie na caly dodatkowy bajt. Pewnie dlatego zrezygnowano z takiego pomyslu. W efekcie jesli czas ma np. 57s to mozesz zapisac 56 albo 58, jak wolisz.

Reply to
T.M.F.

Zdecyduj się o czym piszesz. Windows i jego data to inna bajka, data w systemach plików to inna. Systemy plików też są różne. FAT16, FAT32, NTFS, NFS, XFS, EXT, itd. Jedne zapiszą dokładny czas, inne nie. Dawniej oszczędzano bajtów, dziś gdy dyski mają już po terabajcie pojemności mamy to gdzieś... Co nie zmienia faktu, że rozdzielczość i tak wynosi 1s.

m.

Reply to
Marcin Łukasik <..

Czaq pisze:

heh :-), w 2107 roku nas i FAT-u już nie będzie na 100% wiec nie ma się co tym specjalnie przejmować.

Ja myslałem że meczysz jakiś micro-procesorek wiec nic nie stoi na przeszkodzie aby format zapisu daty stworzyć własny i aby zmiescić się w jakimś zakresie bitów.

pozdr AK

Reply to
Andrzej Kmicic

W ogolnosci jak chcesz :-)

musisz pamietac ze na 16 bitach mozna zakodowac tylko 65536 dni, wiec data bedzie z przedzialu niecalych 200 lat.

Masz chyba na mysli kodowanie daty pliku w MS-DOS/windows. godzin jest 24 wiec potrzeba 5 bitow [z nadmiarem]. Minut jest 60, wiec trzeba 6 bitow. sekund jest 60, wiec trzeba 6 bitow. Razem 17 .. wiec trzeba z czegos zrezygnowac. No to zaokraglamy do najblizszej parzystej sekundy.

A Unix ma to wszystko w d* i date/czas koduje jako ilosc sekund od

1.01.1970. Na 32 bitach ze znakiem. W 2038 bylyby klopoty, ale wszyscy licza ze do tego czasu wszystkie 32 bitowe systemy zastapione zostana 64 bitowymi.

J.

Reply to
J.F.

Andrzej Kmicic schrieb:

nas nie będzie, ale FAT pewnie ocaleje. Jak to było z tymi COBOLowymi programami w latach 60 ub. wieku?

no właśnie. W szkole powinni uczyć sposobów opisu problemu, wtedy z rozwiązaniem go mniejszy problem ;-)

Waldek

Reply to
Waldemar Krzok
Reply to
Włodzimierz Wojtiuk

Do 2017 wymyślą pewnie coś chłodniejszego ;-)

m.

Reply to
Marcin Łukasik <..

2107 znaczy się ;)

m.

Reply to
Marcin Łukasik <..

Marcin Łukasik pisze:

Nie we wszystkich systemach plików i nie każdy z czasów. W takim na przykład NTFS są trzy czasy: utworzenia pliku (rozdzielczość

10ms), ostatniego zapisu do pliku (rozdzielczość 2 sekundy) oraz ostatniego dostępu do pliku (rozdzielczość 1 godziny).

formatting link
Pewnie w innych systemach (różniste unixy) jest jeszcze dziwaczniej.

Reply to
Adam Dybkowski

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.