Egy kalkulátor mellett szereplő friss dátum több dolgot jelenthet. Lehet a cikk megjelenési napja, az adat alkalmazhatóságának kezdete vagy a szerkesztői ellenőrzés ideje. Ha mindhárom ugyanabba a mezőbe kerül, az olvasó és a program is könnyen rossz következtetésre jut.
A forrásadatok kezelésében érdemes külön rögzíteni ezeket az eseményeket. Egy régi dokumentum ma is ellenőrizhető, és egy ma közzétett táblázat későbbi időponttól lehet alkalmazható. Egyik eset sem indokolja az összes dátum automatikus átírását.
Nézzünk egy teljesen szemléltető adatsort
Egy kitalált szolgáltatás díjtáblázatát 2026. szeptember 1-jén teszik közzé. A táblázat szerint az új összegeket 2026. október 1-jétől kell alkalmazni. A szerkesztő 2026. október 17-én nyitja meg, ellenőrzi és rögzíti a forrást.
A három dátum tehát szeptember 1., október 1. és október 17. A díj számításánál az alkalmazandó időszak dönt. Az október 17-i ellenőrzés nem változtatja meg a szeptemberi közzétételt, és nem tolja későbbre az október 1-jei alkalmazási kezdetet.
Ha a szerkesztő már szeptember 20-án ellenőrizte volna a dokumentumot, az október 1-jei érvényességi kezdet szabályosan a jövőben állhatna. Ezzel szemben egy szeptember 20-án készített naplóban az október 17-én „elvégzett ellenőrzés” jövőbeli teljesítésként hibás állítás volna.
Külön mezőhöz külön ellenőrzés tartozik
Az alkalmazhatósági időszaknak lehet kezdete és vége. A szerkesztői ellenőrzéshez a ténylegesen elvégzett művelet dátuma és rövid leírása tartozzon. Például: „a nyilvános táblázat megnyitva, a használt három adat összevetve”.
Egy link technikai elérhetőségének ellenőrzése más bizonyíték, mint a teljes képlet felülvizsgálata. Az ellenőrzés terjedelmét ezért meg kell nevezni. A „frissítve” felirat önmagában egyik műveletet sem írja le egyértelműen.
A forrásban korábban kifejezetten rögzített ellenőrzési dátum átemelhető önálló mezőbe. Ez adatrendezés, az eredeti dátummal. Nem szabad úgy feltüntetni, mintha a mostani feldolgozáskor új szakmai ellenőrzés történt volna.
A dátum valóban létezzen a naptárban
A 2026-02-29 alak megfelelhet egy egyszerű négy számjegy–két számjegy–két számjegy mintának, de 2026-ban nincs február 29. A 2028-02-29 viszont érvényes dátum. A formai és a naptári ellenőrzés ezért két külön lépés.
A Python dátumtípusainak dokumentációja ismerteti a naptári értékek ellenőrzését. A konkrét feldolgozó által elfogadott alakokat is vizsgáld: egy általános ISO-olvasó több alakot fogadhat el, mint a saját rendszeredben előírt YYYY-MM-DD forma.
A dátum napja kalkulátor egy adott nap ellenőrzéséhez kapcsolódik. A forrás alkalmazhatósági szabályát azonban a dokumentum tartalmából kell megállapítani, a hét napjából nem következik.
A frissességi jelzés ne írjon történelmet
Ha egy forrást régen ellenőriztek, a rendszer jelölheti felülvizsgálandónak. A határérték a téma változékonyságától és a projekt szerkesztési szabályától függ. Egy örök érvényű algebrai azonosság és egy időszakos díjtábla eltérő kezelést kívánhat.
A dátumkülönbség-kalkulátorral eltelt napok számolhatók. A lejárt felülvizsgálati határ nem bizonyítja, hogy az adat hibás; azt jelzi, hogy az előírt ellenőrzés esedékes. Friss dátum automatikus beírása csak elfedné ezt az állapotot.
Gyakori kérdések
Melyik dátumot írjam a cikk fejlécébe?
A cikk tényleges közzétételi vagy érdemi módosítási dátumát, egyértelmű címkével. A forrás ellenőrzésének ideje külön jelölést érdemel.
Jövőbeli dátumot minden mezőben el kell utasítani?
Nem. Egy előre meghirdetett alkalmazási kezdet lehet jövőbeli. Egy már elvégzettként rögzített ellenőrzés dátuma viszont nem lehet későbbi a rögzítés valós idejénél.
A hibás dátumot üresre javíthatom?
Csak a hibát megőrző naplóval és egyértelmű hiányjelzéssel. Az eredeti bizonyíték hiányában pontos dátumot nem szabad kitalálni.