By Ether DataRequest data sample
Interactive publication
Back to Time-Interop KB

Edge-case catalogue

Every offset, DST, tzdb, week, instant, dateline, semantics, measurement, precision and data-quality edge case in temporal interoperability, each with detection and mitigation.

Entries
62 across 13 categories
Each entry carries
Detection · mitigation · conversions
On the taxonomy

This catalogue follows the source specification, which files several groups under one "edge-case" heading. Not all 62 are failure modes: the Advertising semantics group (physical presence, home/work location, lookback window, cross-device) are targeting concepts that change what a geometry means, not bugs; the Privacy group are constraints. They live here because each still alters a conversion's result and needs handling - read "case to account for," not "defect."

62 CASES IN 13 CATEGORIES SHOWN
OffsetsDSTTime-zone databaseWeek systemsInstantsDate lineClocksPrecisionSemanticsMeasurementDistributed systemsData qualityAI & agents
01

Offsets

3 CASES
45-minute offset zonesNepal (+5:45), the Chatham Islands (+12:45 / +13:45 DST), and the Australian Eucla region (+8:45) are offset by three quarters of an hour. A local hour straddles a UTC slot 45/15, so even majority assignment is badly lopsided.OPENHalf-hour offset zonesIndia (+5:30), Sri Lanka (+5:30), central Australia ACST (+9:30), Iran (+3:30), Afghanistan (+4:30), Myanmar (+6:30), and Newfoundland (-3:30) sit a half hour off UTC. A local clock hour therefore straddles TWO UTC hour-of-week slots, so a local band (daypart, broadcast day) never maps to a whole number of slots.OPENSub-hour band straddle (general)Because the canonical unit is a whole UTC hour, ANY local band whose edges do not land on a UTC hour boundary produces fractional slot membership — from sub-hour offsets, from bands defined at :30 (e.g. daytime 09:30–16:30), or from DST. This is the same phenomenon as a geo cell straddling a boundary.OPEN
02

DST

6 CASES
DST transition time and date vary by zoneThe '02:00' spring-forward is US-centric. Other zones transition at 00:00, 01:00, 03:00, or 23:00 local, on different dates, and the Southern Hemisphere transitions in the opposite calendar months. Hardcoding a transition time or date is wrong outside one region.OPENFall-back fold (ambiguous local time)When clocks fall back, a local wall time occurs twice (e.g. 01:30 on 2026-11-01 in America/New_York), once at the pre-transition offset and once at the post-transition offset — two different UTC instants, two different slots.OPENNon-DST region inside a DST countryArizona observes no DST while the rest of US Mountain does; Queensland differs from New South Wales. A country name or a 'Mountain Time' label is ambiguous for half the year.OPENPartial-hour DST shiftNot every DST change is one hour. Lord Howe Island shifts by 30 minutes (+10:30 ↔ +11:00); some historical transitions were 20 or 40 minutes. The gap or fold is then a partial hour, so the ambiguity window is not a whole slot.OPENReversed (Southern Hemisphere) DSTDST runs in the opposite calendar months south of the equator, and transition dates differ per country within the same offset. The same UTC slot is a different local season and local hour band in Sydney vs New York.OPENSpring-forward gap (nonexistent local time)When clocks jump forward, a local wall time never occurs (e.g. 02:30 on 2026-03-08 in America/New_York). Resolving it to a slot requires a declared policy, not a silent guess.OPEN
03

Time-zone database

6 CASES
Ambiguous zone abbreviations and bare offsets'IST' means India, Ireland, OR Israel; 'CST' means US Central, China, OR Cuba; 'EST' is used by the US and Australia. Three-letter abbreviations and bare offsets cannot identify a zone or its DST rules.OPENAn offset is not a zoneStoring 'UTC+2' (a fixed offset) instead of 'Europe/Kyiv' (a zone) loses the DST rules, so any FUTURE wall time in that zone resolves wrong. An offset is only valid for one instant.OPENHistorical offset changesBefore standardization zones ran on local mean time, and countries have changed their base offset since (Samoa skipped 2011-12-30 crossing the date line; Venezuela and North Korea shifted by 30 minutes). Old timestamps need the historical offset, not today's.OPENPolitical time change with short noticeGovernments change offsets or DST with days of notice — Lebanon (2023), Egypt and Morocco (Ramadan DST), Samoa, Venezuela. The tzdb lags real life, so systems disagree for a window until they update.OPENTimezone-database vintage mismatchThe IANA tz database is released roughly ten times a year for political changes. Two systems on different releases resolve the same (wall time, zone) to different UTC instants near a changed transition — the temporal analog of a boundary-vintage mismatch in geo.OPENWindows vs IANA zone idsWindows uses display names like 'Eastern Standard Time' where IANA uses 'America/New_York'; the mapping is many-to-one and requires the CLDR windowsZones table.OPEN
04

Week systems

8 CASES
53-week yearsSome ISO years have 53 weeks (when Jan 1 is Thursday, or a leap year starts on Wednesday — e.g. 2026). Code that assumes 52 weeks misaligns year-over-year comparisons and drops a week.OPENBroadcast (Nielsen) calendar month and quarterThe broadcast month is a whole number of broadcast weeks and does not align to the calendar month; a broadcast quarter has 13 or 14 weeks; the broadcast year boundary differs from the calendar. Rollups reconcile only within one calendar.OPENBroadcast-day cutover is not universalThe broadcast day does not always start at 06:00 local — some operations use 05:00, 02:00, or midnight, and sports/overnight feeds differ. An undeclared cutover silently reassigns early-morning events to the wrong day.OPENCompeting week-numbering systemsISO weeks start Monday; US/retail weeks often start Sunday; broadcast (Nielsen) weeks start Monday but sit inside a different month calendar; some Middle-Eastern weeks start Saturday or Sunday. 'Week 29' is ambiguous without the system.OPENMovable and regional holidaysEaster-derived dates move each year (computus), lunar-calendar holidays (Eid, Diwali, Lunar New Year) shift against the Gregorian calendar, and many holidays are regional (US state, Canadian province, German Land). A single national list is incomplete.OPENSlot-origin conventionThe canonical origin is slot 0 = Monday 00:00 UTC. A system that assumes a Sunday-start week is off by 24 slots; one that anchors on local midnight disagrees with the UTC origin by the zone offset.OPENSubstitute (in-lieu) holiday daysWhen a public holiday falls on a weekend, many countries observe a substitute weekday instead (UK 'bank holiday in lieu', much of APAC). The observed date is not the calendar date, so a naive fixed-date rule flags the wrong day.OPENWeek-year ≠ calendar yearThe ISO week-numbering year can differ from the calendar year around January 1 — 2027-01-01 belongs to 2026-W53, and 2026-12-31 can fall in the next year's W01. Carrying a week number without its week-year is a bug.OPEN
05

Instants

2 CASES
Epoch and unit confusionSeconds vs milliseconds vs microseconds, and non-Unix epochs (NTP 1900, Apple 2001, Windows FILETIME 1601), place events off by 1000× or in the wrong century — a whole dataset lands in one slot or in 1970.OPENLeap secondsUTC has inserted 27 leap seconds since 1972, so a day is occasionally 86,401 seconds; Google and AWS 'smear' the leap second over 24 hours, disagreeing with UTC by up to ~0.5 s. Negligible for hour-of-week bucketing, but real for high-precision joins. (Leap seconds are being phased out by ~2035.)OPEN
06

Date line

2 CASES
Date-line weekday divergenceAcross the International Date Line the same UTC instant is a different local weekday. Kiribati (+13/+14) and Samoa (+13) are a full day ahead of the Americas, so an event's local weekday can differ from the weekday of its UTC slot — the temporal analog of the geo antimeridian.OPENExtreme offset span (UTC−12 … +14)The inhabited world spans 26 hours of offset, so a single local hour exists across a more-than-24-hour span of UTC instants. A local daypart aggregated across many zones can therefore occupy a UTC slot-set that wraps the entire week.OPEN
07

Clocks

10 CASES
Clock-accuracy metadataA GPS fix (~20 ns), a phone clock (~100 ms), and a server clock (~5 ms) are not interchangeable. Treating every timestamp as equally precise hides which slot assignments are safe and which are near a boundary.OPENClock-correction jumpsAfter synchronization, NTP can step a clock several seconds backwards (rather than slewing), so consecutive events straddle a discontinuity and can invert in order.OPENContainer / live migrationA container or VM moved between hosts inherits a different clock quality and synchronization history, so timestamp reliability changes mid-stream without any application signal.OPENMonotonic vs wall clockA monotonic clock (performance.now(), CLOCK_MONOTONIC) measures elapsed time from an arbitrary origin and has no fixed epoch, so it cannot be converted to UTC or a slot. Mixing monotonic and wall-clock timestamps silently corrupts latency analysis.OPENMultiple clock authorities disagreeGPS, PTP, and NTP can disagree during outages or holdover. Which authority wins determines the timestamp, and the choice is often undocumented.OPENNTP synchronization stateA device whose clock is unsynchronized can be minutes off while still emitting well-formed timestamps. The format is valid; the value is not.OPENOffline capture, delayed replayIoT and mobile devices capture events offline and upload them later, so yesterday's events arrive today. Arrival order is not occurrence order, and late data reopens already-reported slots.OPENTimestamp confidence intervalAn instant is a point estimate plus an error bar — 12:03:10 ±150 ms, not a single moment. Near an hour boundary the ±window straddles two slots, so the assignment is not unique (the temporal weighted crosswalk).OPENTimestamp provenance (which time became canonical)Sensor time, API time, database time, and client time are different instants. Which one became the canonical event time (and therefore the slot) is a modeling decision that must travel with the value, exactly like geometry provenance in the geo KB.OPENVM snapshot rollbackRestoring a virtual machine from a snapshot moves its clock backwards, so a later event can carry an earlier timestamp than an earlier one.OPEN
08

Precision

5 CASES
Averaged timestampOne timestamp that summarizes thousands of observations (a mean or a bucket label) is not an instant; the observations it stands for span a range and may cross slot boundaries.OPENFalse precisionA timestamp stored to nanoseconds from a clock accurate only to ±1 second implies precision the source never had. The extra digits are noise that can flip a near-boundary slot assignment.OPENInterval center vs start vs endIs a 10:00 reading the beginning, midpoint, or end of a one-hour measurement? The convention shifts every value by up to an hour and is rarely recorded.OPENMixed-precision datasetSome rows carry seconds, others milliseconds, others nanoseconds. A single numeric parse then places rows off by factors of 1000, scattering them across the wrong slots or epochs.OPENSampling window vs instantA timestamp can denote a measurement INTERVAL rather than a moment — a one-minute average, a five-minute scrape. Treating the interval as an instant drops the fact that it may span multiple slots.OPEN
09

Semantics

2 CASES
Event vs ingestion vs report timeWhen something HAPPENED, when it was LOGGED, and when it is ATTRIBUTED are three different instants that fall in three different slots. Reports silently mix them.OPENUTC canonical vs local experienceThe unit is UTC, but 'primetime', 'morning', and 'lunch' are LOCAL experiences (8pm local everywhere). Comparing behavior at the same UTC slot is not the same as at the same local hour — the core temporal-interop tension, and the direct analog of geo's requested-vs-executed geography.OPEN
10

Measurement

3 CASES
Attribution-window timeA conversion is credited to an earlier impression, so the 'slot' of a conversion depends on the attribution model — the conversion's own time, or the attributed impression's time.OPENNo silent temporal rollupA buyer requests hourly (slot) delivery or reporting and the platform reports at day or week grain. The temporal analog of geo's no-silent-rollup rule: coarsening the time grain is the buyer's operation, not a quiet default.OPENSlot-boundary dedup and double-countAn event, session, or airing that spans a slot boundary can be counted in two slots or dropped — the temporal analog of geo's touching-only / duplicate eligibility.OPEN
11

Distributed systems

5 CASES
Duplicate event replayAt-least-once delivery replays the same event, with an identical event timestamp but a new ingestion time. Naive counting double-counts the slot.OPENEvent versioning and correctionsAn event is corrected later while its original occurrence time is preserved. The correction has a new processing time but the same event time, so the slot stays put while the value changes.OPENLamport / vector clocks (causal ≠ UTC order)Causal order and UTC order are different relations. A can happen-before B while A's UTC timestamp is later, because of queue delay, retry, or skew. Event sourcing and multi-agent systems need the causal order.OPENMessage-queue delay and reorderingKafka, SQS, and similar queues delay and reorder delivery, so arrival order at a consumer is not production order. Slotting by arrival time misplaces events.OPENPartial ordering onlyTwo events on different nodes cannot always be globally ordered — there may be no fact of the matter about which came first. A UTC total order imposed on them is an artifact of clock skew, not causality.OPEN
12

Data quality

5 CASES
Clock skew and sentinel timestampsDevice clocks are wrong; bidstream timestamps can be in the future or negative; missing values default to 1970-01-01 (the temporal 'zero-island'); rounded values pile up at 00:00:00. These are not real slots.OPENLocal timestamps read as UTC (or vice versa)A column stored in local time is read as UTC, or a UTC column is read as local. Every event shifts by the offset, biasing every slot systematically — the diurnal curve peaks at the wrong hour.OPENNaive datetime with no zoneA stored '2026-03-08 02:30' with no offset and no accompanying zone cannot be resolved to a slot — and, unluckily, that particular value does not even exist in US Eastern. Zone-less local timestamps are the most common warehouse hazard.OPENTimestamp rounding / truncationTimestamps truncated to the day or hour for storage or privacy lose hour-of-week signal; a date-only value cannot be placed in a slot at all.OPENTimezone inferred from geographyBidstream and sensor data often lack a reliable device timezone, so it is inferred from a lat/long via a timezone-boundary shapefile — a GEO × TIME crosswalk. A wrong zone shifts the local hour and the daypart. A lat/long is a location plus an error bar, and so is the tz lookup it feeds.OPEN
13

AI & agents

5 CASES
AI-inferred timestampA timestamp reconstructed by an LLM or by interpolation is a model output, not an observation. Treating an inferred time as measured injects unquantified error into every slot it lands in.OPENEmbedding validity timeAn embedding or feature computed months ago may no longer represent today's semantics. The datum has two times — when the event happened and when the representation was valid — and joining on the wrong one drifts the model.OPENModel training window (temporal leakage)A model trained on data that would not have been available at prediction time leaks the future into the past. The slot a datum belongs to is not the slot at which it was knowable.OPENPrediction time vs observation timeA forecast generated on Monday for Friday has two times — when it was made and what it is about. Storing only one makes the forecast unauditable and mixes horizons.OPENSynthetic event timeSimulated or generated data carries fabricated timestamps that must never masquerade as measured time, or backtests and training sets silently mix real and synthetic history.OPEN