feat(prezentacja): strefa czasowa z lokalizacji — DST-świadomy offset (PRE-03) #43
Reference in New Issue
Block a user
Delete Branch "feat/pre03-timezone"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Pierwsza z zaplanowanych iteracji (A1). „Logika dwóch lokalizacji": dotąd offset
GMT był ręcznym polem (PRE-19) — trzeba było go znać i samemu pamiętać o czasie
letnim. Teraz liczymy go z lokalizacji, offline.
Sedno wymagania
Strefę ustalamy raz i trzymamy jako stałą liczbę w formularzu, żeby drobna
zmiana współrzędnych nie przerzuciła DST i nie „przeskoczyła" Ascendenta na
sąsiedni znak. „Większa miejscowość z bazy" okazuje się zbędna — strefa IANA jest
i tak regionalna, więc wioska daje tę samą strefę co pobliskie miasto (dlatego
wystarczą dokładne współrzędne).
Jak
timezone.py: współrzędne → strefa IANA (tzfpy, offline — działa bez sieci),a z niej offset dla daty urodzenia.
zoneinfo/tzdataznają regułyhistoryczne i DST. Degraduje się do
None(brak biblioteki / punkt bez strefy /zła data) — zostaje wtedy ręczny offset, nic się nie psuje.
GET /timezone?lat&lon&date&time→{tz, offset, dst, label}; 404 gdy nieda się ustalić.
geo.js: po wyborze miejsca (mapa / wyszukiwarka / „Tu i teraz") oraz przyzmianie daty (DST zależy od pory roku) wypełnia pole
tz_offseti pokazuje„Wykryto: Europe/Warsaw · +2:00 (czas letni)". Pole zostaje edytowalne; na wejściu
podpowiada tylko gdy offset wygląda na nieustawiony — nie nadpisuje wartości
ręcznie wpisanej i wysłanej.
Zależności
Lekkie i offline:
tzfpy(wheel Rust) +tzdata(dlazoneinfow slim-obrazie).Zero danych od użytkownika — zgodnie z priorytetem „bez danych z zewnątrz".
Weryfikacja
Żywy serwer: Kraków 1984-06 → +2:00 (czas letni), 1984-01 → +1:00,
Katmandu → +5:45. Testy: +12 strefa (moduł + endpoint na żywej aplikacji),
+5 JS. Prezentacja 187.
Domyka PRE-03 (Must). Następne z planu: A2 (wiele systemów domów naraz), A3
(eksport wyników do Excela), A4 (cache-busting).
„Logika dwóch lokalizacji": dotąd offset GMT był ręcznym polem (PRE-19) — trzeba było go znać i samemu pamiętać o czasie letnim. Teraz liczymy go z lokalizacji. Sedno wymagania: strefę ustalamy RAZ i trzymamy jako stałą liczbę, żeby drobna zmiana współrzędnych nie przerzuciła DST i nie „przeskoczyła" Ascendenta na sąsiedni znak. „Większa miejscowość z bazy" okazuje się zbędna — strefa IANA jest i tak regionalna, więc wioska daje tę samą strefę co pobliskie miasto. Jak: - `timezone.py`: współrzędne → strefa IANA (tzfpy, OFFLINE — bez sieci), a z niej offset DLA DATY URODZENIA. `zoneinfo`/`tzdata` znają reguły historyczne i DST: Kraków 1984 to +1h zimą, +2h latem; Katmandu +5:45. Degraduje się do None (brak biblioteki / punkt bez strefy / zła data) — wtedy zostaje ręczny offset. - Endpoint `GET /timezone?lat&lon&date&time` → {tz, offset, dst, label}. 404, gdy nie da się ustalić. - `geo.js`: po wyborze miejsca (mapa / wyszukiwarka / „Tu i teraz") oraz przy zmianie DATY (bo DST zależy od pory roku) pobiera offset i wypełnia pole tz_offset, pokazując wykrytą strefę („Wykryto: Europe/Warsaw · +2:00 (czas letni)"). Pole zostaje edytowalne. Na wejściu podpowiada tylko gdy offset wygląda na nieustawiony — nie nadpisuje wartości ręcznie wpisanej i wysłanej. Zależności (lekkie, offline): tzfpy (wheel Rust) + tzdata (dla zoneinfo w slim-obrazie). Weryfikacja: żywy serwer — Kraków 1984-06 → +2:00 (czas letni), 1984-01 → +1:00, Katmandu → +5:45. Testy: +12 strefa (moduł + endpoint), +5 JS. Prezentacja 187. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>