alice.mosphere.at / tidface
this repo has no description
0
fork

Configure Feed

Select the types of activity you want to include in your feed.

remove status

alice 15a81486 b0d48760

-53
-53
scripts/status.md
··· 1 - # Project Status Report: Timezone List Generation (TS Conversion) 2 - 3 - **Date:** 2025-04-24 4 - 5 - **Goal:** Convert the Python script `generate_airport_tz_list.py` to TypeScript (`generateAirportTzList.ts`), ensuring functional equivalence and correctness in generating the `src/c/airport_tz_list.c` file. Performance optimization was a secondary goal. 6 - 7 - **Summary:** 8 - 9 - The conversion is largely complete, but debugging focused on achieving correct timezone bucket counts and DST transition timestamps compared to the original Python version and IANA definitions. Performance tuning was attempted but led to correctness issues, prioritizing correctness for now. 10 - 11 - **Key Issues Encountered & Resolutions:** 12 - 13 - 1. **Initial Performance:** The initial TS script was significantly slower than Python. 14 - * **Attempted Fix:** Implemented memoization for `geo-tz` lookups and DST transition calculations. Introduced an optimized `findDstTransitions` in `tzCommon.ts` using day-by-day iteration + binary search for the exact hour. 15 - * **Status:** Optimization attempts complicated correctness analysis (see point 5). Performance is currently secondary to correctness. 16 - 17 - 2. **Missing Timezone (`America/Noronha` / FEN):** The TS script initially missed the bucket for Fernando de Noronha (IATA: FEN). 18 - * **Root Cause:** The `airport-data` package provided an incorrect timezone (`America/Fortaleza`) for FEN. 19 - * **Resolution:** Added a manual data fix step in `generateAirportTzList.ts` immediately after loading airport data to force FEN's timezone to `America/Noronha`. Verified with debug logs and external sources (Wikipedia). 20 - * **Status:** Resolved. FEN and its corresponding timezone bucket (UTC-2, no DST) are now correctly generated. 21 - 22 - 3. **Bucket Count Discrepancy:** Initial comparisons showed TS generating 60 buckets while a specific Python run generated 61. 23 - * **Root Cause:** Analysis revealed Python (`zoneinfo`) created a separate bucket for `Africa/Casablanca` (0 -> +1 offset) due to its unique 2025 Ramadan DST schedule, while Luxon (TS) initially grouped it with `Europe/London` (also 0 -> +1 offset). Python also had a bug where it failed to assign FEN to the `America/Noronha` bucket. 24 - * **Resolution:** Confirmed the Python FEN assignment was a bug. Ensured TS uses a strict 4-value key (`std_offset`, `dst_offset`, `start_ts`, `end_ts`) for bucketing, which *should* correctly separate Casablanca if Luxon provides distinct transition timestamps. 25 - * **Status:** The strict bucketing logic is in place in TS. The final bucket count depends on Luxon's data/logic for 2025 Casablanca DST. 26 - 27 - 4. **DST Timestamp Discrepancy:** Systematic differences were observed between Luxon and `zoneinfo` timestamps for DST transitions. 28 - * **Root Cause:** Luxon returns the precise UTC timestamp of the offset change instant. `zoneinfo` returns the UTC timestamp corresponding to the *local* "wall clock" time of the transition (e.g., 2 AM local). 29 - * **Resolution:** Decided Luxon's approach (UTC instant) is technically more correct according to IANA definitions and prioritizes correctness over matching the previous Python implementation's specific behavior. 30 - * **Status:** Using Luxon's default timestamp calculation. 31 - 32 - 5. **`tzCommon.ts` Loop Accuracy:** The optimized day+binary search loop introduced for performance produced different results than the simple hour-by-hour loop. 33 - * **Observation:** The optimized loop resulted in 58 buckets, merging zones (like Beirut/Chisinau) that the slow loop correctly separated (resulting in 60 buckets). Timestamps also differed slightly. 34 - * **Resolution:** Prioritizing verifiable correctness, the decision was made to revert `tzCommon.ts` to the **slower, hour-by-hour iteration** method. 35 - * **Status:** The hour-by-hour loop is currently active in `tzCommon.ts`. 36 - 37 - **Current State (as of 2025-04-24T18:18:00Z):** 38 - 39 - * `scripts/generateAirportTzList.ts`: Contains the FEN data fix and uses strict 4-value bucketing. 40 - * `scripts/tzCommon.ts`: Contains the **slow, simple hour-by-hour loop** for `findDstTransitions`. 41 - * The last run (using the optimized loop) generated `src/c/airport_tz_list.c` with **58 buckets**. 42 - * The previous run using the *slow* loop generated **60 buckets**, which appeared more correct. 43 - 44 - **Next Immediate Step:** 45 - 46 - 1. Run `npm run generate:airport` with the current codebase (using the slow loop in `tzCommon.ts`). 47 - 2. Verify the console output reports **60 buckets**. 48 - 3. Inspect the generated `src/c/airport_tz_list.c` to confirm the structure and timestamps match expectations based on the previous reliable "slow loop" run (e.g., check separation of Beirut/Chisinau). 49 - 50 - **Future Considerations:** 51 - 52 - * If the ~4-minute runtime of the slow loop becomes unacceptable, revisit the optimized day+binary search in `tzCommon.ts` to identify and fix the cause of the timestamp discrepancies compared to the hour-by-hour method. 53 - * Consider adding automated tests comparing generated bucket counts and key timestamps against known values for specific years/zones.