Čas v telefonu není čas skutečnosti

Ve forenzním výpisu je jediný řádek, který jako by rozhodoval celý případ. U fotografie nalezené v telefonu stojí čas 22:17:08. Na snímku je vchod domu, před ním zaparkované auto a v odrazu skla část člověka, jehož přítomnost je předmětem sporu. O několik minut později se na tom místě něco stalo. Majitel telefonu tvrdí, že už tam nebyl.

Čas fotografie působí objektivněji než výpověď. Svědek se může mýlit. Podezřelý může lhát. Paměť se přepisuje. Ale telefon přece nemá motiv. Do tabulky zapsal 22:17, a tím jako by uzavřel prostor pro pochybnost: fotografie vznikla ve 22:17, telefon byl ve 22:17 na místě a jeho majitel tam tedy byl také.

Pak se otevře podrobnější výpis stejného souboru. Vedle údaje DateTimeOriginal: 22:17:08 se objeví další: File created: 22:43:51. V aplikační databázi je navíc hodnota 2026-06-14T20:18:14.622Z. A cloudová historie uvádí synchronizaci až následující den ve 03:12:04.

Čtyři údaje. Jeden soubor. Který čas je „správný“?

Nejpohodlnější odpověď zní, že jeden z nich musí být chybný. Přesnější odpověď je nepříjemnější: pravdivé mohou být všechny. Každý však může popisovat jinou technickou událost. A žádný z nich sám o sobě nemusí dokazovat přesně to, co jsme se rozhodli z něj vyčíst.

Čas potřebuje sloveso

Samotné „22:17“ není tvrzení o minulosti. Je to hodnota. Význam získá teprve ve chvíli, kdy k ní připojíme sloveso: fotografie byla pořízena, zpráva byla odeslána, soubor byl vytvořen, data byla přijata, záloha byla obnovena. Právě toto sloveso bývá místem, kde se technický údaj nenápadně promění v příběh.

Digitální systém totiž obvykle nezapisuje „okamžik skutečné události“. Zapisuje změnu svého vlastního stavu: vznik položky v databázi, přijetí požadavku serverem, uložení souboru do adresáře, změnu obsahu, synchronizaci nebo zobrazení údaje uživateli. Odborná literatura proto rozlišuje mezi pozorovaným artefaktem, technickou událostí, kterou může reprezentovat, a širší událostí ve fyzickém světě, kterou se analytik snaží rekonstruovat. Časový řádek v nástroji není sám událostí; je stopou po změně, jejíž význam je nutné nejprve určit.^[1]

Položit správnou otázku tedy znamená rozebrat jednu jednoduchou větu na pět vrstev: který systém zaznamenal jakou změnu, podle kterých hodin, v jaké časové reprezentaci a jak ji následně zobrazil použitý program. Teprve potom lze rozhodovat, k jaké části skutečného děje se údaj vztahuje.

Jedna fotografie, nejméně čtyři děje

Fotografie je ideální past, protože vypadá jako jediný předmět. Ve skutečnosti může nést několik časových vrstev, které vznikly v různých okamžicích a na různých místech.

Uvnitř souboru může být EXIF údaj DateTimeOriginal, určený pro čas vzniku původních obrazových dat. U digitálního fotoaparátu či telefonu zpravidla vychází z hodin zařízení v okamžiku pořízení. Samotný text ale nemusí obsahovat informaci o časovém pásmu; standard zná samostatné údaje pro časový posun, ty však nemusí být přítomné. EXIF lze při exportu odstranit, při úpravě změnit nebo vůbec nevytvořit. Jeho přesný význam a zachování proto závisejí na zařízení, formátu, aplikaci a verzi.^[10]

Vedle toho existují časy souborového systému. Čas vytvoření typicky říká, kdy vznikl tento konkrétní souborový objekt v tomto konkrétním úložišti. Když se fotografie stáhne z cloudu, přijme v komunikátoru, obnoví ze zálohy nebo překopíruje na nové zařízení, může být „vytvořena“ dlouho po pořízení. Čas modifikace může označovat poslední zápis obsahu nebo jinou změnu podle pravidel konkrétního systému. Čas přístupu zase nemusí být přesným okamžikem, kdy si člověk obrázek prohlédl: některé systémy jeho aktualizaci odkládají, omezují nebo pracují s hrubším rozlišením. Microsoft například dokumentuje, že NTFS uchovává časy v UTC, zatímco FAT pracuje s místním časem, a že aktualizace posledního přístupu může být opožděná.^[6]

Pak přichází aplikační vrstva. Galerie si může vytvořit náhled, mediální index může zařadit soubor do katalogu, komunikační aplikace může evidovat přijetí přílohy a cloud může zaznamenat upload nebo synchronizaci. Každá operace může vytvořit vlastní timestamp. Nejde o čtyři verze téhož času. Jde o časy čtyř různých dějů, které se sbíhají kolem jednoho obsahu.

Kdyby analytik z času vytvoření souboru odvodil čas pořízení fotografie, nemusel by pracovat s padělaným údajem. Mohl by použít dokonale autentický timestamp — jen by k němu připojil nesprávné sloveso.

Kdo měl hodinky

Ještě složitější je čas komunikace. Zpráva může mít čas vytvoření v klientském zařízení, čas zařazení do fronty, čas odeslání, přijetí serverem, doručení do účtu příjemce, stažení do jeho telefonu a pozdější synchronizaci. V běžném rozhraní se přitom může zobrazit jediné číslo a jedno neurčité slovo: „odesláno“.

Rozdíl není akademický. Telefon může být bez signálu. Uživatel stiskne tlačítko ve 22:17, ale aplikace odešle obsah až ve 22:26. Serverový čas pak spolehlivě dokládá, kdy server data přijal, nikoli nutně kdy uživatel učinil gesto. Naopak klientský čas může být blíže lidské akci, ale závisí na hodinách zařízení. Ty mohou být nastavené automaticky ze sítě, ručně posunuté, krátkodobě nesynchronizované nebo změněné po cestě mezi časovými pásmy.

Čas klientského zařízení je čas odvozený z hodin telefonu či počítače, na němž uživatelská akce nebo lokální zápis proběhly. Čas serveru pochází z hodin vzdáleného systému a obvykle popisuje okamžik, kdy server požadavek přijal, zpracoval nebo uložil. Serverový údaj bývá lépe synchronizovaný a hůře ovlivnitelný uživatelem telefonu, ale není tím automaticky časem lidské akce. Klientský údaj může být lidské akci bližší, avšak nese stav hodin zařízení.

Současná metodika SWGDE pro mobilní forenzní analýzu výslovně upozorňuje, že datum a čas telefonu mohou pocházet z mobilní sítě nebo z ručního nastavení, mohou se lišit od skutečného času či pásma a zjištěný rozdíl je nutné v analýze zaznamenat. Stejná metodika připomíná, že přesné artefakty a jejich funkce závisejí na hardwaru, operačním systému, firmwaru, aplikaci, verzi a konfiguraci.^[4]

Síťová synchronizace času tuto nejistotu výrazně snižuje, ale nemaže ji. NTP nefunguje jako razítko absolutní pravdy; odhaduje odchylku hodin vůči časovým zdrojům a pracuje také se zpožděním, rozptylem a očekávanou chybou. Systém může hodiny korigovat postupně nebo skokem podle implementace. Pro analýzu je proto důležité nejen to, zda zařízení „mělo automatický čas“, ale zda existují záznamy o synchronizaci, změně pásma nebo korekci hodin v relevantním období.^[9]

UTC není místo, kde se událost stala

Časové pásmo je další vrstva, která se při běžném čtení ztrácí. Zápis 2026-06-14T20:18:14Z označuje okamžik v UTC. V Praze se tentýž okamžik v období letního času zobrazí jako 22:18:14. Nejde o dva různé děje ani o dvouhodinovou chybu. Jde o dvě reprezentace stejného okamžiku.

Unixový timestamp jde ještě dál: typicky ukládá počet sekund od epochy 1. ledna 1970 v UTC. Hodnota 1781468294 sama neobsahuje „pražský čas“ ani informaci, kde byl telefon. Teprve software ji přeloží na datum a čas pro zvolené pásmo. Některé systémy navíc používají milisekundy, mikrosekundy nebo jiné epochy. Záměna sekund a milisekund není posun o hodinu; může vytvořit datum, které vypadá absurdně — a přesto jde jen o chybnou interpretaci jednotky.

Je také rozdíl mezi časovým posunem a časovým pásmem. Hodnota +02:00 říká vztah k UTC v daném okamžiku. Označení Europe/Prague nese soubor pravidel, podle nichž se posun mění v historii a při přechodu mezi letním a zimním časem. Moderní internetové standardy proto rozlišují pevný timestamp s UTC offsetem a doplňující informaci o pojmenovaném pásmu.^[8]

Při podzimním návratu hodin se stejný místní čas může vyskytnout dvakrát. „02:30“ bez data, pásma a offsetu pak nemusí označovat jediný okamžik. Při jarním posunu naopak některé místní časy vůbec nenastanou. A pokud program použije dnešní pravidla pásma k převodu staršího lokálního údaje, může se výsledek lišit od programu, který pracuje s historickými pravidly nebo jen s pevným posunem.

Proto je nutné odlišit uloženou hodnotu od jejího zobrazení. Dva nástroje mohou nad stejnými bajty ukázat 20:18 a 22:18, aniž by kterýkoli timestamp změnily. Rozdíl vytvořila konverze.

Cloud dává datům druhý život

Telefon už dávno není uzavřená krabička. Fotografie může vzniknout na jednom zařízení, být odeslána přes server, automaticky uložená do cloudu, stažena do notebooku, upravena, znovu synchronizována a nakonec obnovena do nového telefonu. V každém kroku vznikají legitimní časové stopy.

Cloudová služba může evidovat vytvoření objektu ve svém úložišti, poslední změnu cloudové kopie, upload, generování náhledu, sdílení, stažení nebo synchronizaci. To, co její rozhraní nazve „created“, nemusí být okamžik vzniku původního obsahu. Metodika SWGDE upozorňuje, že čas vytvoření cloudového objektu může odpovídat stažení či přesunu, čas modifikace může odrážet synchronizaci namísto uživatelské změny a časové pásmo záznamu nemusí být na první pohled zřejmé.^[5]

Migrace a obnova ze zálohy vytvářejí zvláštní druh časové iluze. Nový telefon může obsahovat zprávu starou tři roky, ale soubor databáze byl na zařízení vytvořen včera. Obrázek si může zachovat původní EXIF, zatímco jeho souborový čas vytvoření odpovídá obnově. Aplikace může importovat staré aplikační timestampy do nově vytvořené databáze. Žádný z těchto údajů nemusí být vadný. Každý jen sleduje jinou kontinuitu: obsah, databázový záznam, soubor nebo zařízení.

Změna zařízení proto obrací běžnou intuici. Nález „v telefonu“ nemusí znamenat, že data v telefonu vznikla. Může dokazovat, že byla do telefonu synchronizována, importována nebo obnovena. A nepřítomnost starého souborového času nemusí znamenat, že obsah dříve neexistoval; mohla se ztratit při kopírování mezi systémy, které uchovávají jiné typy metadat.

Cloud přitom není jen zdrojem zmatku. Často poskytuje nezávisleji vedený serverový čas, historii verzí nebo záznamy, které lokální zařízení už neobsahuje. Jeho síla ale vzniká až tehdy, když analytik ví, jaký proces dané pole popisuje a zda porovnává opravdu nezávislé zdroje. Tři hodnoty odvozené z jediné cloudové události nejsou automaticky třemi nezávislými potvrzeními.

Databáze neukládá „čas“. Ukládá dohodu o čase

V databázi může timestamp vypadat nejpřesvědčivěji: dlouhé číslo s milisekundami působí vědecky. Jenže databáze často neví, co číslo znamená. Ví pouze, že v určitém sloupci leží celé číslo, desetinná hodnota nebo text.

SQLite, běžně používaná v mobilních i desktopových aplikacích, nemá samostatný datový typ datum/čas. Časové hodnoty lze ukládat jako text v podobě ISO 8601, juliánské číslo dne nebo unixový timestamp. Význam pak doplňuje schéma aplikace a kód, který hodnotu zapisuje a čte.^[7] Sloupec nazvaný created_at může obsahovat sekundy od roku 1970, milisekundy od stejné epochy, lokální text bez pásma nebo serverový čas. Název pole je nápověda, nikoli důkaz jeho přesné sémantiky.

Ještě důležitější je otázka, kdo hodnotu vytvořil. Zapsal ji klient podle hodin telefonu? Doplnil ji server při přijetí požadavku? Byla převzata z importovaného záznamu? Aktualizovala ji synchronizace? Někdy databáze uchovává zároveň čas vytvoření obsahu, čas poslední změny záznamu a čas poslední synchronizace. Když se všechny tři sloupce převedou do jediné časové osy bez znalosti jejich významu, vznikne krásně seřazená, ale věcně falešná historie.

To je důvod, proč odborná interpretace potřebuje dokumentaci a ověření na srovnatelném systému. Přesné chování se může změnit mezi verzemi aplikace. Aktualizace může přesunout čas z klienta na server, změnit jednotku nebo zavést nové pole. Tam, kde dokumentace chybí, je legitimním závěrem nejistota — nikoli sebejisté přiřazení nejpravděpodobnějšího významu.

Když čas překládá nástroj

Mezi surovým artefaktem a člověkem obvykle stojí program. Forenzní nástroj načte bajty, rozpozná formát, rozhodne, zda číslo představuje sekundy či milisekundy, přiřadí mu epochu, převede ho do UTC nebo do nastaveného pásma a přidá popisek. Každý krok může být správný — a každý přidává interpretaci.

Proto může grafické rozhraní zobrazit lokální čas, zatímco export do CSV obsahuje UTC. Jeden analytik může mít projekt nastavený na pásmo důkazního zařízení, druhý na vlastní místní čas. Starší verze parseru může stejné pole označit jinak než novější. A některý program může lokální text bez pásma převést podle nastavení počítače, přestože zařízení bylo v době události jinde.

Rozumná časová analýza proto uchovává tři podoby údaje: surovou hodnotu, dekódovaný význam a zobrazenou hodnotu v uvedeném pásmu. K tomu patří verze nástroje, nastavení projektu a způsob extrakce. Ne proto, že by nástrojům nebylo možné věřit, ale proto, že jsou překladateli. NIST po přezkumu vědeckých základů digitálního vyšetřování shrnuje, že používané techniky vycházejí ze zavedených metod informatiky a při správném použití jsou považovány za spolehlivé.^[3] Slova „při správném použití“ jsou zde podstatnější než značka softwaru.

Autenticita, správnost hodin a důkazní význam jsou tři odlišné otázky. Hodnota může být autenticky uložená v původní databázi, ale pocházet z chybně nastavených hodin. Může být časově přesná, ale označovat serverové přijetí místo pořízení snímku. A může správně dokazovat přenos dat, aniž by dokazovala, kdo držel telefon.

Síla vzniká v průsečíku

Vraťme se k fotografii z úvodu. EXIF uvádí 22:17:08, ale neobsahuje jistou informaci o pásmu. Server eviduje přijetí ve 20:18:14.622 UTC, tedy ve 22:18:14 místního letního času. Síťová stopa ukazuje přenos mezi 22:18:12 a 22:18:16. Telefon příjemce soubor uloží ve 22:43:51 a cloud ho synchronizuje v noci.

Z těchto údajů nelze poctivě prohlásit, že spoušť byla stisknuta přesně ve 22:17:08. Lze však říci něco jiného: pokud je prokázáno, že server přijal právě tento obsah, musel existovat nejpozději ve 22:18:14. Síťová stopa podporuje stejnou posloupnost. EXIF je slučitelný s pořízením přibližně minutu před odesláním, ale jeho váha závisí na správnosti hodin zařízení a integritě metadat. Čas vytvoření souboru ve 22:43 nepopisuje pořízení; dobře odpovídá pozdějšímu uložení kopie.

Správná časová osa proto nevzniká mechanickým seřazením všech timestampů. Vzniká tím, že se každému údaji přiřadí původ, hodiny, formát, možné odchylky a technická událost. Potom se hledají souhlasné posloupnosti, rozpory a časové kotvy: serverové logy, záznamy synchronizace, síťové události, data z dalšího zařízení nebo jiné stopy, jejichž vztah k externímu času je lépe známý.

Výsledkem nemusí být bod. Často je jím interval a pořadí: obsah už existoval; poté byl přenesen; později se objevil v tomto telefonu; nakonec byl synchronizován. Takový závěr je možná méně dramatický než jedno tučné „22:17“, ale bývá podstatně přesnější.