Miért?

https://msdn.microsoft.com/en-us/library/ms675098%28v=vs.85%29.aspx

This value represents the number of 100-nanosecond intervals since January 1, 1601 (UTC). A value of 0 or 0x7FFFFFFFFFFFFFFF (9223372036854775807) indicates that the account never expires.

BlackY

És egy user fiók lejártának mi köze a FILETIME struktúrához [a Remarks közt emlegették, tehát azt tudom, hogy onnan jön, azt nem tudom, hogy MIÉRT]? Egy user fiók lejártához minek kell 100 nanosec-es pontosság? Szerk.: És persze - miért tervezünk olyan adatstruktúrát, amivel egy felhasználót a rendszer elindulási előtti pillanatban visszamenőleg lehet tiltani?

Mindezt persze úgy, hogy a de facto editorban (ADUC) _dátum_ szinten lehet kezelni ezt a mezőt [kivéve az attrib. editort, ahol int-ként]. Ja, és beállítva 1601 január elsejét, az 828000000000 értéket írja be - vagyis még a math sem jön ki nicely, mert 8.2 másodpercet téved. ;)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

"És egy user fiók lejártának mi köze a FILETIME struktúrához [a Remarks közt emlegették, tehát azt tudom, hogy onnan jön, azt nem tudom, hogy MIÉRT]? Egy user fiók lejártához minek kell 100 nanosec-es pontosság? Szerk.: És persze - miért tervezünk olyan adatstruktúrát, amivel egy felhasználót a rendszer elindulási előtti pillanatban visszamenőleg lehet tiltani?"

Win NT-n 1601. jan. 1. az epoch, olyan mint unixon az 1970. jan. 1. Azt lehet vitatni, hogy mennyire volt ertelmes dolog ezt egy ~400 evvel ezelotti datumra rakni, de azert az eleg furcsa lenne, ha a rendszer minden funkcioja mashonnan/mas felbontasban szamolna az idot, mert hogy "ide nem is kell 100 ns pontossag, eleg 37.4ms is!".

--
"You're NOT paranoid, we really are out to get you!"

De pont ezt csinálják:

Not all file systems can record creation and last access time and not all file systems record them in the same manner. For example, on NT FAT, create time has a resolution of 10 milliseconds, write time has a resolution of 2 seconds, and access time has a resolution of 1 day (really, the access date). On NTFS, access time has a resolution of 1 hour.

https://msdn.microsoft.com/en-us/library/ms724284%28v=vs.85%29.aspx

Vagyis az egyetlen helyen, ahol a FILETIME névnek értelme lehet (fájlokhoz kapcsolódó időpontok...) nincs egységes felbontás. (NTFS create time-ról nincs szó, azon se lennék meglepődve, ha az se 100 ns felbontásban menne, vagyis még csak ki sincs használva az overengineeringelt felbontás)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Az nem baj hogy az implementációk nem tudnak ilyen felbontást, nagyobb precizitással lehet kisebb precizitású számokat tárolni, fordítva nem. Ez egy ~15 éves struktúra és még ki tudja meddig lesz támogatott, azalatt hány fájlrendszer támogatása fordul meg a windowsokban (a 3rd party fs támogatásról se feledkezzünk meg), azok milyen felbontással fognak rendelkezni. Pl. gondolj a unix timestampre és az Y2038 problémára, még van addig pár év de már most megy az átállás 64 bites reprezentációra. Ha a hetvenes években gondol valaki arra, hogy esetleg 68 év múlva a unix timestamp még velünk lehet, akkor eleve nem egy 32 bites signed integert használtak volna.

Egyfelől jogos, amit mondasz, lehet az ágyúval verébre menni és minden egységesen az elképzelhető legnagyobb pontossággal ábrázolni, szerintem nem mindig szerencsés.

A time_t-nél ugye ott van a másodperces bontás. Ha pontosabb kell, akkor meg ott a timeval, nanosec pontossághoz meg a timespec [ha jól kerestem, hál istennek ritkán van közöm C-hez]. Vagyis van megoldás arra, hogy finomíts, ha szükséges van rá.

A másik oldal, az adatok hossza... valahol jogos, de még van 25 évünk arra, hogy újraforgassunk mindent egy módosított typedef-ű time_t-vel :) És persze, bele lehet ugrani csúnya dolgokba, amikor növeljük az ábrázolás hosszát, attól még ezt is lehet "mértékkel" csinálni (lásd az IPv6-ot. Azzal is MESSZE túllőttünk a célon és még ha újabb 20 év is lesz, mire bevezetjük, szerintem 64 bites címekkel lenne egy kényelmesen évszázadunk, mire megint "elfogytak a címek, jaj, IPv8" :) )

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Almat a kortevel hasonlitasz. Linuxon ugyanis gyakorlatilag minden cserelheto a kerneltol az Apache-ig, megsem valtozik erdemben az oprendszer. Windows eseteben viszont nincs ilyen, minden egyes upgrade gyakorlatilag egyenerteku egy uj operacios rendszer felrakasaval, raadasul nagyon sokszor nem frissulnek a szoftverek, meg mindig hasznalunk olyan szoftvereket, amiekt eredetileg W98-hoz irtak, az pedig igencsak nem mostanaban volt.

A Windows eseteben hosszu tavon kell API-t tervezniuk, a FILETIME struktura erre alkalmas. Persze, bevezethetnenek kevesbe pontos strukturakat is, akarcsak Linuxon, de pontosan mi ertelme lenne? Hogy konvertalgatni lehessen? A FILETIME lefed minden olyan felhasznalasi igenyt, ami elofordulhat a Windows internal hivasokban, nem is ertem, miert van 3 kulonbozo struktura ugyanannak az informacionak a leirasara Linuxon.
--
Blog | @hron84
Üzemeltető macik

Konvertálgatni - pl. mentéskor - így is kell (lásd a fenti fájlrendszerekre vonatkozó pontossági leírásokat). Nekem továbbra is korrektebbnek tűnik az a megoldás, hogy az általános implementáció egy "good enough" pontosságot ad, de ha akarsz, kérhetsz le külön pontosabbat. Kíváncsi lennék egy statisztikára, hogy hány helyen használnak a time_t-nél pontosabb timestamp-eket. - ugyanúgy, ahogy random adatbáziskezelőben is van 3-4-10+ adattípus, ami a dátumokra/időkre vonatkozik [és ott is mindig a fejem fogom, amikor látom, hogy valaki datetime-ként tárolja pl. a születési dátumot...]

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Valszeg ez lesz (közben ránéztem egy angol ADUC-ra, ott korrektebb "End of:" cimre szerepel), UTC-re állított rendszerórával rendesen 864000000000 kerül be (hogy miért a helyi gép időzónáját veszi [rsat, tehát a szerver órája/időzónája közben állandó], az egy más kérdés, ha nem dátum szintű lenne a "vállalt" felbontás, akár security bugnak is lehetne is minősíteni).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( asch v | 2015. 06. 30., k – 22:50 )

Mert ha egyszer ki van dolgozva egy értelmes időkezelő formátum a hozzávaló metódusokkal (konverzió agyba főbe), akkor onnantól kezdve a legésszerűbb mindenhol azt használni.

Nagyon ki van dolgozva (a FILETIME-nál ugyanez leírva, használd 64 bites számként és számolj vele...):

It is not recommended that you add and subtract values from the SYSTEMTIME structure to obtain relative times. Instead, you should
Convert the SYSTEMTIME structure to a FILETIME structure.
Copy the resulting FILETIME structure to a ULARGE_INTEGER structure.
Use normal 64-bit arithmetic on the ULARGE_INTEGER value.

https://msdn.microsoft.com/en-us/library/ms724950%28v=vs.85%29.aspx

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)