astrololo

gitea/astrololo

Fork 0

Commit Graph

Author	SHA1	Message	Date
gitea	4bdfb673cc	feat(prezentacja): strefa czasowa z lokalizacji — DST-świadomy offset (PRE-03) Testy / Testy warstwy logicznej (silnik) (pull_request) Successful in 11m2s Details Testy / Testy warstwy prezentacji (dostęp do baz) (pull_request) Successful in 9m56s Details Testy / Build obrazu silnika B (swisseph) (pull_request) Successful in 34s Details Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 23s Details build / build (push) Successful in 1m40s Details Testy / Testy warstwy logicznej (silnik) (push) Successful in 11m12s Details Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m52s Details Testy / Build obrazu silnika B (swisseph) (push) Successful in 32s Details Testy / Kontrola składni wszystkich warstw (push) Successful in 19s Details „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>	2026-07-28 22:42:31 +02:00
gitea	f34016a4a5	feat(prezentacja): wspolne dane formularza miedzy zakladkami + imie i nazwisko (PRE-21) build / build (push) Successful in 58s Details Testy / Testy warstwy logicznej (silnik) (push) Successful in 11m4s Details Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m53s Details Testy / Build obrazu silnika B (swisseph) (push) Successful in 38s Details Testy / Kontrola składni wszystkich warstw (push) Successful in 25s Details Trzecia wskazowka partnerow. Kazda zakladke (Horoskop / Interpretacje / Kalendarz) wypelnialo sie od nowa — te same imie, data, godzina, strefa i miejsce. Teraz raz wpisane dane wedruja za uzytkownikiem, a zmiana w jednej zakladce przenosi sie na pozostale. Nowy formsync.js trzyma stan w localStorage. Dlaczego nie sesja na serwerze: serwer zostaje BEZSTANOWY — zadnego magazynu sesji, zadnych danych urodzeniowych trzymanych po stronie uslugi (spojne z postawa z LOG-32/PRE-16). Przy okazji dane synchronizuja sie tez miedzy osobnymi kartami przegladarki, bo zdarzenie `storage` daje to za darmo. Dolozone pole „imie i nazwisko" (wszystkie trzy zakladki) — potrzebne do naglowka raportu PDF (PRE-24). Handlery przyjmuja je i oddaja, wiec nie znika po przeliczeniu. Dwie rzeczy, ktore trzeba bylo domknac, zeby to dzialalo naprawde: 1. KOLEJNOSC SKRYPTOW. formsync.js ladowany w <head> z `defer` — skrypty defer wykonuja sie w kolejnosci dokumentu, wiec ten zdazy odtworzyc wspolrzedne, ZANIM geo.js zbuduje mape. Mapa startuje od razu we wlasciwym miejscu, zamiast przeskakiwac po chwili. 2. geo.js ustawia pola z KODU (`.value = ...`), co samo z siebie NIE wywoluje zdarzen — bez tego synchronizacja przegapilaby kazdy wybor z mapy, z wyszukiwarki i z „Tu i teraz". Dolozony setVal(), ktory jawnie zglasza `change`. Zakladka bez danego pola (np. Sygnifikatory) nie kasuje wartosci zapamietanej gdzie indziej; uszkodzony wpis w localStorage nie blokuje formularza. Q-14 rozstrzygniete: lancuch LaTeX->PDF stanie jako OSOBNA USLUGA render — spojne z izolacja swisseph (LOG-27), obraz produktu zostaje maly. Weryfikacja na zywym stacku (data+logika+prezentacja) w przegladarce: dane wpisane w Horoskopie pojawily sie w Interpretacjach; zmiana godziny w Interpretacjach dotarla do Kalendarza; pola nieobecne na zakladce (zodiak, system domow) przetrwaly; po POST imie zostalo, a horoskop policzyl sie normalnie. Testy: 22 nowe strukturalne. Calosc: prezentacja 67 passed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-24 15:12:49 +00:00
gitea	5c82e8bd9f	fix(prezentacja): offset wzgledem GMT + nazwa lokalizacji po „Tu i teraz” Dwie pierwsze wskazowki od partnerow biznesowych; pozostale piec zapisane jako wymagania (PRE-21..PRE-24) do zrobienia w kolejnych krokach. PRE-19 — offset wzgledem GMT. Etykieta mowila „Strefa (offset h)”, czyli nie bylo jasne, wzgledem czego liczymy przesuniecie. Teraz „Offset wzgledem GMT (h)” z podpowiedzia. Krok juz byl 15-minutowy (0,25 h) — dolozony zakres −12…+14, zeby nie dalo sie wpisac strefy, ktora nie istnieje. Zmiana w trzech zakladkach, ktore maja to pole (Horoskop, Interpretacje, Kalendarz). PRE-20 — po „Tu i teraz” wspolrzedne i pineska skakaly na biezace polozenie, ale w polu tekstowym zostawala STARA, wczesniej wpisana nazwa. Formularz pokazywal jedno miejsce, a liczyl dla innego — cicha pomylka, nic sie nie wywalalo. Handler zdarzenia astrololo:coords odswieza teraz nazwe przez reverseName. Przy okazji druga strona tego samego bledu: reverseName czysci pole ZANIM wysle zapytanie. Gdyby /reverse nie odpowiedzialo (brak sieci), zostalaby stara nazwa — lepiej puste pole i poprawne wspolrzedne niz nazwa, ktora klamie. Wymagania: PRE-19/20 (zrobione), PRE-21 wspolne dane miedzy zakladkami wraz z polem imie i nazwisko, PRE-22 wiele predykcji okresowych w pamieci sesji, PRE-23 zakladka „Skompiluj”, PRE-24 raport PDF przez LaTeX. Dolozone pytanie otwarte Q-14 o lancuch LaTeX→PDF (gdzie postawic TeX Live, silnik unicode owy pod glify, konwersja SVG) — decyzja wplywa na deploy i rozmiar obrazow. Testy: 12 nowych, strukturalnych na zrodle (JS-a nie uruchomimy, a obie regresje sa ciche). Sprawdzone sabotazem — po cofnieciu kazdej poprawki czerwienieja. Calosc: prezentacja 45 passed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-24 15:12:49 +00:00

Author

SHA1

Message

Date

gitea

4bdfb673cc

feat(prezentacja): strefa czasowa z lokalizacji — DST-świadomy offset (PRE-03)

Testy / Testy warstwy logicznej (silnik) (pull_request) Successful in 11m2s

Details

Testy / Testy warstwy prezentacji (dostęp do baz) (pull_request) Successful in 9m56s

Details

Testy / Build obrazu silnika B (swisseph) (pull_request) Successful in 34s

Details

Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 23s

Details

build / build (push) Successful in 1m40s

Details

Testy / Testy warstwy logicznej (silnik) (push) Successful in 11m12s

Details

Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m52s

Details

Testy / Build obrazu silnika B (swisseph) (push) Successful in 32s

Details

Testy / Kontrola składni wszystkich warstw (push) Successful in 19s

Details

„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>

2026-07-28 22:42:31 +02:00

gitea

f34016a4a5

feat(prezentacja): wspolne dane formularza miedzy zakladkami + imie i nazwisko (PRE-21)

build / build (push) Successful in 58s

Details

Testy / Testy warstwy logicznej (silnik) (push) Successful in 11m4s

Details

Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m53s

Details

Testy / Build obrazu silnika B (swisseph) (push) Successful in 38s

Details

Testy / Kontrola składni wszystkich warstw (push) Successful in 25s

Details

Trzecia wskazowka partnerow. Kazda zakladke (Horoskop / Interpretacje /
Kalendarz) wypelnialo sie od nowa — te same imie, data, godzina, strefa
i miejsce. Teraz raz wpisane dane wedruja za uzytkownikiem, a zmiana w jednej
zakladce przenosi sie na pozostale.

Nowy formsync.js trzyma stan w localStorage. Dlaczego nie sesja na serwerze:
serwer zostaje BEZSTANOWY — zadnego magazynu sesji, zadnych danych urodzeniowych
trzymanych po stronie uslugi (spojne z postawa z LOG-32/PRE-16). Przy okazji
dane synchronizuja sie tez miedzy osobnymi kartami przegladarki, bo zdarzenie
`storage` daje to za darmo.

Dolozone pole „imie i nazwisko" (wszystkie trzy zakladki) — potrzebne do
naglowka raportu PDF (PRE-24). Handlery przyjmuja je i oddaja, wiec nie znika
po przeliczeniu.

Dwie rzeczy, ktore trzeba bylo domknac, zeby to dzialalo naprawde:

1. KOLEJNOSC SKRYPTOW. formsync.js ladowany w <head> z `defer` — skrypty defer
   wykonuja sie w kolejnosci dokumentu, wiec ten zdazy odtworzyc wspolrzedne,
   ZANIM geo.js zbuduje mape. Mapa startuje od razu we wlasciwym miejscu,
   zamiast przeskakiwac po chwili.

2. geo.js ustawia pola z KODU (`.value = ...`), co samo z siebie NIE wywoluje
   zdarzen — bez tego synchronizacja przegapilaby kazdy wybor z mapy, z
   wyszukiwarki i z „Tu i teraz". Dolozony setVal(), ktory jawnie zglasza
   `change`.

Zakladka bez danego pola (np. Sygnifikatory) nie kasuje wartosci zapamietanej
gdzie indziej; uszkodzony wpis w localStorage nie blokuje formularza.

Q-14 rozstrzygniete: lancuch LaTeX->PDF stanie jako OSOBNA USLUGA render —
spojne z izolacja swisseph (LOG-27), obraz produktu zostaje maly.

Weryfikacja na zywym stacku (data+logika+prezentacja) w przegladarce: dane
wpisane w Horoskopie pojawily sie w Interpretacjach; zmiana godziny w
Interpretacjach dotarla do Kalendarza; pola nieobecne na zakladce (zodiak,
system domow) przetrwaly; po POST imie zostalo, a horoskop policzyl sie
normalnie. Testy: 22 nowe strukturalne. Calosc: prezentacja 67 passed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-24 15:12:49 +00:00

gitea

5c82e8bd9f

fix(prezentacja): offset wzgledem GMT + nazwa lokalizacji po „Tu i teraz”

Dwie pierwsze wskazowki od partnerow biznesowych; pozostale piec zapisane jako
wymagania (PRE-21..PRE-24) do zrobienia w kolejnych krokach.

PRE-19 — offset wzgledem GMT. Etykieta mowila „Strefa (offset h)”, czyli nie
bylo jasne, wzgledem czego liczymy przesuniecie. Teraz „Offset wzgledem GMT (h)”
z podpowiedzia. Krok juz byl 15-minutowy (0,25 h) — dolozony zakres −12…+14,
zeby nie dalo sie wpisac strefy, ktora nie istnieje. Zmiana w trzech zakladkach,
ktore maja to pole (Horoskop, Interpretacje, Kalendarz).

PRE-20 — po „Tu i teraz” wspolrzedne i pineska skakaly na biezace polozenie, ale
w polu tekstowym zostawala STARA, wczesniej wpisana nazwa. Formularz pokazywal
jedno miejsce, a liczyl dla innego — cicha pomylka, nic sie nie wywalalo.
Handler zdarzenia astrololo:coords odswieza teraz nazwe przez reverseName.

Przy okazji druga strona tego samego bledu: reverseName czysci pole ZANIM
wysle zapytanie. Gdyby /reverse nie odpowiedzialo (brak sieci), zostalaby stara
nazwa — lepiej puste pole i poprawne wspolrzedne niz nazwa, ktora klamie.

Wymagania: PRE-19/20 (zrobione), PRE-21 wspolne dane miedzy zakladkami wraz
z polem imie i nazwisko, PRE-22 wiele predykcji okresowych w pamieci sesji,
PRE-23 zakladka „Skompiluj”, PRE-24 raport PDF przez LaTeX. Dolozone pytanie
otwarte Q-14 o lancuch LaTeX→PDF (gdzie postawic TeX Live, silnik unicode owy
pod glify, konwersja SVG) — decyzja wplywa na deploy i rozmiar obrazow.

Testy: 12 nowych, strukturalnych na zrodle (JS-a nie uruchomimy, a obie regresje
sa ciche). Sprawdzone sabotazem — po cofnieciu kazdej poprawki czerwienieja.
Calosc: prezentacja 45 passed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-24 15:12:49 +00:00

3 Commits