Film nagrano w Bangkoku o 14:15, a mój Mac pokazuje 8:15

Na moim Macu film znad jeziora w Bangkoku ma w informacjach o pliku datę 6 marca 2024 i godzinę 8:15, ale... nagrano go wczesnym popołudniem, o 14:15 tamtejszego czasu. To nie żaden błąd, bo Mac pokazuje tę samą chwilę, tylko w czasie polskim, który w marcu był o sześć godzin za tajskim.

Kliposkop to narzędzie, które buduję od zera razem z agentami AI i które ma odczytywać z pliku wideo to, czego nie widać na samym obrazie, a w tym wpisie biorę się za czas, czyli za to, kiedy nagrano film. Na tym etapie narzędzie nie korzysta z żadnego modelu AI (wystarcza zwykły program) i nie potrzebuje internetu.

Dwa zegary w jednym pliku

Telefon (u mnie iPhone) zapisuje w pliku chwilę nagrania więcej niż raz. Pierwszy zapis to data w nagłówku pliku w formacie QuickTime (to format plików wideo opracowany przez Apple), a specyfikacja tego formatu zaleca, żeby tę datę podawać w czasie UTC, czyli uniwersalnym, wspólnym dla całego świata i niezależnym od stref czasowych. Drugi zapis telefon dodaje od siebie: to godzina lokalna razem z przesunięciem względem UTC (dla Bangkoku to plus siedem godzin, dla Chicago w lipcu minus pięć), więc z tego jednego zapisu da się odczytać i godzinę na miejscu, i strefę czasową, w której nagrano film.

Komputer pokazuje jeszcze trzecią datę, czyli datę modyfikacji pliku na dysku. Nie jest ona częścią filmu i kopiowanie pliku może ją zmienić, ale w moich 23 filmach testowych zgadza się co do sekundy z chwilą nagrania, tylko że komputer pokazuje ją w swojej strefie czasowej. Dla filmu znad jeziora wygląda to tak:

Zapis	Gdzie jest i w jakim czasie	Godzina
Data zapisana przez telefon	w pliku, czas lokalny z przesunięciem	14:15:14, plus siedem godzin
Nagłówek QuickTime	w pliku, czas UTC	7:15:14
Data modyfikacji pliku	na dysku, w strefie komputera	8:15:14 na Macu w Polsce

Któremu zegarowi wierzy narzędzie

Narzędzie bierze godzinę lokalną zapisaną przez telefon, bo tylko z niej od razu wiadomo, która była godzina na miejscu i w jakiej strefie czasowej, a czas UTC wylicza z niej, odejmując przesunięcie (14:15 minus siedem godzin to 7:15, dokładnie tyle, ile jest w nagłówku). Nagłówek służy mu do sprawdzenia: jeśli oba zegary różnią się o więcej niż dwie sekundy, narzędzie zgłasza rozbieżność, ale zostawia godzinę z telefonu. Te dwie sekundy to zapas na zaokrąglenia, bo oba zegary liczą pełne sekundy, a w trzech moich filmach różnią się właśnie o jedną (dla człowieka to wciąż ta sama chwila).

Jeśli telefon zapisał godzinę bez przesunięcia, narzędzie dopisuje do niej strefę czasową miejsca, a jeśli tej godziny w pliku w ogóle nie ma, bierze godzinę z nagłówka i przelicza ją na strefę miejsca. Gdy nie zna też miejsca (bo film nie ma współrzędnych), podaje tylko czas UTC i nie zgaduje, w jakiej strefie nagrano film. W moich 23 filmach przesunięcie jest w każdym, więc z tego zapasowego sposobu narzędzie nie musiało jeszcze skorzystać przy żadnym prawdziwym nagraniu i na razie sprawdzają go tylko testy.

Zgadywanie strefy potrafi narobić zamieszania i widziałem to już w prototypie podobnego narzędzia, który zbudowałem wcześniej, przy zdjęciach z godziną zapisaną bez przesunięcia. Godzinę 18:43 ze zdjęcia zrobionego w Bangkoku prototyp potraktował tak, jakby była w czasie UTC, i wyszła z tego 1:43 w nocy, a w opisie sceny pojawiła się noc zamiast wieczoru. Filmy z tego wpisu mają przesunięcie zapisane w pliku, więc tutaj ten problem się nie pojawił.

Strefa czasowa miejsca

Przesunięcie zapisane w pliku narzędzie porównuje jeszcze ze strefą czasową miejsca, w którym nagrano film. Baza GeoNames, z której narzędzie bierze nazwy miejsc, podaje przy nich także strefę czasową w zapisie bazy IANA, na przykład Asia/Bangkok albo America/Chicago (to wspólna baza stref czasowych, w której jest też historia zmian czasu na letni i zimowy, a korzystają z niej systemy operacyjne i programy). Narzędzie sprawdza, czy w chwili nagrania ta strefa miała dokładnie takie przesunięcie, jakie zapisał telefon. Taki test wyłapałby na przykład telefon, który wciąż ma ustawiony czas z domu, albo źle odczytane miejsce. W moich 23 filmach przesunięcie zgadza się ze strefą wszędzie, także w dwóch nagranych w Minnesocie, która ma ten sam czas co Chicago.

Wieczór, który w nagłówku jest już następnym dniem

Trzy filmy z Chicago nagrano wieczorem 11 lipca 2025, między 19:19 a 20:32, ale w nagłówku, czyli w czasie UTC, jest już 12 lipca, od 0:19 do 1:32. Program, który brałby datę z nagłówka, przypisałby te filmy do niewłaściwego dnia, a mój Mac w Polsce pokazuje przy nich nawet 12 lipca, od 2:19 do 3:32 w nocy. Narzędzie podaje datę lokalną, czyli 11 lipca, i zaznacza przy tych filmach, że data w nagłówku to już inny dzień.

Dwa zegary, dwanaście dni różnicy

W jednym pliku dwa zegary różnią się o 12 dni.

Najdziwniejszy jest jeden film z ulicy w Bangkoku: telefon zapisał w nim godzinę lokalną 12 marca 2024, 15:35, a w nagłówku jest 24 marca, 11:18 w czasie UTC (czyli 18:18 w Bangkoku), to znaczy 12 dni, 2 godziny i 43 minuty później. Data modyfikacji pliku zgadza się z godziną zapisaną przez telefon, a w pliku jest ta sama wersja oprogramowania telefonu co w pozostałych dziesięciu filmach z Bangkoku. Skąd się wzięła ta różnica, tego w pliku nie widać, a narzędzie w takiej sytuacji podaje godzinę z telefonu, zgłasza, że zegary się rozjechały, i niczego nie zgaduje.

Agent AI napisał ten moduł w trzy i pół minuty

Temat tego etapu i ramy całej serii ustaliłem wcześniej (jeden mały temat na wpis, a na tym etapie bez modelu AI i bez internetu). Pracą kierował agent AI, który najpierw sam przejrzał, co jest zapisane w plikach filmów, a potem przekazał drugiemu agentowi regułę (któremu zegarowi wierzyć i co z czym porównać). Ten drugi w ciągu około trzech i pół minuty napisał moduł (czyli tę część narzędzia) razem z testami. Odczytanie czasu ze wszystkich 23 filmów trwało około półtorej sekundy, a testy narzędzia (jest ich 166) nie wykazują żadnych błędów.

Ja na tym etapie jeszcze niczego nie sprawdzałem. Różnica 12 dni dobrze pokazuje, ile agent zrobi sam i co zostaje dla człowieka: narzędzie ją zgłasza, ale... skąd się wzięła, to już pytanie, na które odpowiedzi trzeba szukać poza plikiem.

Na tym etapie Kliposkop odczytuje z filmu czas i robi to bez modelu AI i bez internetu, tylko że sama godzina z pliku to jeszcze nie odpowiedź, bo trzeba wiedzieć, który zegar ją zapisał i w jakiej strefie czasowej.

Strefy czasowe miejsc w tym wpisie pochodzą z bazy GeoNames, udostępnionej na licencji CC BY 4.0.

W skrócie

• Telefon zapisuje w pliku wideo chwilę nagrania co najmniej dwa razy: w nagłówku QuickTime w czasie UTC i od siebie jako godzinę lokalną z przesunięciem względem UTC.
• Kliposkop bierze godzinę lokalną zapisaną przez telefon, a nagłówek służy mu do sprawdzenia, czy oba zegary się zgadzają (z zapasem dwóch sekund).
• Narzędzie porównuje przesunięcie z pliku ze strefą czasową miejsca z bazy GeoNames i w moich 23 filmach testowych przesunięcie zgadza się ze strefą wszędzie, także w Minnesocie, która ma czas Chicago.
• Mac pokazuje datę pliku w swojej strefie czasowej, dlatego film nagrany w Bangkoku o 14:15 ma u mnie godzinę 8:15. W nagłówku, czyli w czasie UTC, trzy wieczorne filmy z Chicago mają już datę następnego dnia.
• W jednym filmie z Bangkoku zegary różnią się o 12 dni, 2 godziny i 43 minuty, a w pliku nie widać, skąd ta różnica: narzędzie zgłasza rozbieżność i niczego nie zgaduje.