eeu.ti — Time-Info / DST Rule Table

Status: ✅ Cracked · 485 bytes · NOT_COMPRESSED · Purpose, grouping, and the timezone field confirmed by exhaustive real-world geography; byte positions assigned for all 14 remaining named fields. 3 of them (monthorweek/starthour/startminute) are now confirmed to NOT store literal per-zone calendar/clock data (they're identical even on records with zero real DST events) — likely a template/subtype discriminator instead; the real "duration" fields remain the most promising unresolved content.

The real "timeinfo" table eeu.cny's own timeinfo_id field points into — and a real Daylight Saving Time (DST) / UTC-offset table, confirmed (not just plausible) by joining every county on the disc through to its real country and checking against Russia's actual 11 time zones. Only 17 records — small enough to fully hand-inspect in one pass.

Record format

94-byte header (record count 17 read straight from the header), then exactly 17 fixed 23-byte records:

uint16 LE  timeinfo_id  -- 1-13, matches eeu.cny's own timeinfo_id
                            range exactly; NOT a per-record primary key
                            — multiple physical records share one value
uint16 LE  timezone     -- CRACKED (exact formula, see below):
                            utc_offset_hours = value/100 - 12
uint8      seqnr         -- a clean 0, 1, 2 sub-entry counter within
                             one timeinfo_id group
bytes[18]  ...           -- 14 more named fields, byte positions
                            assigned (1 byte/field, 14 bytes used + 4
                            reserved) — see "record shapes" below

timezone — cracked, confirmed against real-world geography

utc_offset_hours = timezone_field/100 - 12. Validated exhaustively against Russia's own real federal-district geography, which this disc's data happens to span all 11 of Russia's real UTC offsets:

timeinfo_id	timezone	Implied UTC	Real Russian region
2	1400	UTC+2	Severo-Zapadniy (NW) — Kaliningrad's zone
4	1500	UTC+3	Moscow Time (shared with Belarus, Turkey)
5	1600	UTC+4	Privolzhskiy/Yuzhniy
6	1700	UTC+5	Uralskiy (Yekaterinburg)
7	1800	UTC+6	Sibirskiy
8	1900	UTC+7	Sibirskiy (Novosibirsk/Krasnoyarsk)
9	2000	UTC+8	Sibirskiy (Irkutsk)
10	2100	UTC+9	Sibirskiy/Dalnevostochniy (Yakutsk)
11	2200	UTC+10	Dalnevostochniy (Vladivostok)
12	2300	UTC+11	Dalnevostochniy (Magadan/Sakhalin)
13	2400	UTC+12	Dalnevostochniy (Kamchatka)

All 11 real Russian time zones, west to east, exactly right, zero exceptions. Also confirmed for the disc's 2 DST-observing zones: timeinfo_id=1 → 1300 → UTC+1, the real standard-time offset of Central European Time; timeinfo_id=3 → 1400 → UTC+2, real Eastern European Time.

The id/country correspondence

Joining eeu.cny → eeu.stt → eeu.ctr for every county on the disc reveals the whole file's purpose at once:

• timeinfo_id=1 (72% of counties, the "rich" 3-entry group): every real Central European Time country on the disc — Germany, Italy, Poland, Switzerland, Austria, Czechia, Slovakia, Hungary, the Balkans, Scandinavia, Vatican City, San Marino, Liechtenstein.
• timeinfo_id=3 (17%, also "rich"): every real Eastern European Time country — Bulgaria, Estonia, Greece, Latvia, Lithuania, Moldova, Romania, Finland, Ukraine.
• Every other id (each a "simple", single-record group): Russia (across its own 11 real time zones, above) plus Belarus and Turkey (sharing timeinfo_id=4, Moscow Time).

This is not a coincidence. Russia permanently abolished DST in 2014, Belarus does not observe DST, and Turkey abolished DST in 2016 (this disc's own version strings date it to 2019) — exactly the 3 non-DST-observing country groups on the disc, and exactly the ids with no detailed sub-schedule. The 2 DST-observing zones (CET, EET) are exactly the 2 ids with a real 2-rule sub-schedule (seqnr=0/seqnr=1, a "spring forward"/"fall back" pair) plus a seqnr=2 terminator; every non-DST id has just 1 simple "no schedule" record.

Grouping

17 physical records cover only 13 distinct timeinfo_id values: timeinfo_id=1 has 3 sub-records (seqnr 0, 1, 2); timeinfo_id=3 has 3 sub-records; every other value has exactly 1 (3 + 3 + 11×1 = 17, exact). timezone is constant within each group.

Cross-validated exactly against eeu.cny's own timeinfo_id distribution

timeinfo_id=1 covers 1,674/2,326 counties (72%), timeinfo_id=3 covers 398/2,326 (17%) — together 89% of every county on the disc, exactly matching which 2 ids carry real DST sub-schedules here.

Record shapes — byte positions assigned, not every field's exact semantics confirmed

The 14 named fields map 1:1 onto bytes[5:19] in eeu.mod's own field order (typeofentry, startyear, monthorweek, flcount, startday, starthour, startminute, durationnegative, durationyears, durationmonths, durationweeks, durationdays, durationhours, durationminutes), with bytes[19:23] always zero.

• "Real entry" (4 records — both seqnr=0/seqnr=1 records in each DST zone): typeofentry=121; startyear=77 (constant — plausibly a reference/epoch year rather than a real calendar year, since an annually-recurring rule doesn't need one); monthorweek=108 (constant across BOTH DST zones and both seqnr=0/seqnr=1 — identical for "spring forward" (March) and "fall back" (October) within the same zone, not just across zones); starthour=3 (seqnr=0) or 10 (seqnr=1); durationmonths increases monotonically across sub-entries (2, 3, 3, 4); durationminutes=8 constant.

  REFUTED (a still later session): monthorweek/starthour/ startminute are not literal per-zone calendar/clock facts. The original guess compared only the 2 DST zones to each other. Checking against the 11 "simple default" (non-DST) records below seals it: every one of them also carries starthour=3 — including records encoding no real transition event at all (every duration field zero). A byte genuinely storing "the DST transition hour" could never appear unchanged on a record with no transition. Likewise monthorweek only ever takes 2 values across the entire real dataset — 100 on every non-DST record, 108 on every DST record, regardless of spring vs fall — more consistent with a coarse record-subtype/template discriminator than a real month-or-week value. If real per-zone/per-season calendar data exists on this disc at all, it isn't stored in these particular bytes. The "duration" fields remain the most promising real content in this shape — their pattern (~1 year, a growing month count, ~8 minutes) doesn't match a real 1-hour DST clock shift, so they may encode a rule validity window rather than the shift amount — still not resolved.

• "Simple default" (11 singleton records): byte-for-byte identical across all 11 (typeofentry=121, startyear=77, monthorweek=100 — different from the DST zones' 108, consistent with "no real transition" — starthour=3 (the direct evidence for the refutation above) — everything else 0).

• "Terminator" (2 seqnr=2 records): typeofentry=42, everything else 0.

Reader code

research/ti_reader.py — read_ti(), utc_offset().