Repository navigation
Conversation
stain
marked this pull request as draft
October 23, 2026 01:13
2 tasks done
stain
force-pushed
the
event-timezone-inference
branch
2 times, most recently
from
October 23, 2026 08:00
97278cf to
d63e58c
Compare
…d JSON-API
TeSS stores an event's start and end as local (wall clock) time in a
UTC column, with the zone in timezone. Bioschemas startDate/endDate
gave that time with Time#to_s ("2026-10-22 09:00:00 UTC", not ISO
8601) and JSON-API as "2026-10-22T09:00:00.000Z", both presenting the
local time as UTC: an event at 09:00 in Buenos Aires was given as 09:00
UTC rather than 12:00 UTC.
Give them in ISO 8601 with the offset of the event's time zone on that
date (Event#local_iso8601), e.g. "2026-10-22T09:00:00-03:00", or
without an offset, as local time, when the time zone is unknown. The
legacy JSON API is left unchanged.
See ElixirTeSS#1391
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
TeSS stores event times as local (wall clock) time, with the zone in the event's timezone. The iCalendar, Indico and Gray Scott ingestors stored DTSTART;TZID=... times converted to UTC instead, so e.g. a 09:45 event in Perth was shown as 01:45 Perth time, and exported to iCal and Google Calendar 8 hours early. All-day dates became midnight in the server's time zone. Store the local time of the calendar (Ingestor#ical_local_time). Upcoming events are corrected when their source is ingested again. The ingestor tests now check the actual UTC time (start_utc) and the local time with its offset, rather than the stored column. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The new event form defaulted to 09:00-17:00 in the server's system time zone (DateTime.now), giving e.g. 00:00-08:00 on a server in Tokyo, and the event calendar used the server's date (Date.today). Use the application time zone (Time.zone.now, Date.current). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Events without a time zone were exported to iCal and Google Calendar as UTC, so e.g. a 09:00-17:00 event in Australia appeared from 20:00 to 04:00 the next day. Export them as floating local times (DTSTART:20261105T090000), which calendars show at the same clock time and day in their own time zone, assuming people are near the event. The Google Calendar link now gives the IANA time zone (ctz=Australia/Perth rather than Perth). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A short developer note on local (wall clock) storage with a separate time zone, exports, default times, and what ingestors and their tests need to do. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Most events have no time zone, so their times cannot be placed. When an event without one is saved, look it up offline from its coordinates (timezone-boundary-builder polygons, via the wheretz gem) or, failing that, from a country with a single time zone, as one of the time zone names TeSS accepts. Online events often have neither and keep none. The time zone is marked as inferred (new timezone_inferred column), shown as "(inferred)" on the event page and in JSON-API, until it is changed, e.g. by the user. Events given only dates get 09:00-17:00 by default; these are now marked with a new time_inferred column, kept when the event is saved again with the same times (e.g. from the form), and cleared when a time of day is given. No time zone is inferred for them, as a guessed time zone on top of guessed times would pin them to a time and day that may not apply, while their floating local times show on the right day. An inferred time zone is cleared if the times become inferred again, e.g. when the event is ingested again from a source that only gives dates. Existing events get a time zone when they are next saved, e.g. when their source is next ingested. See ElixirTeSS#1391 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The event form suggests the time zone of the location when none is selected, and warns when the selected one differs (ignoring time zones with the same offsets, e.g. Edinburgh and London), with a button to use it. This is advice only: the user can keep their own choice. It is updated when the time zone, country, city or postcode change, or the address finder sets a location; if the address fields are edited by hand after the address finder, only the country is used. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
stain
force-pushed
the
event-timezone-inference
branch
from
October 23, 2026 08:03
d63e58c to
b1438ef
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary of changes
Depends on #1393 (event time fixes); only the last two commits are new here.
(timezone-boundary-builder polygons via the
wheretzgem), or from a countrywith a single time zone. A time zone set by the user or the source is never changed.
timezone_inferred(shown as "London (inferred)" on the event page) andtime_inferred(the09:00–17:00 defaults for events given only dates). Both are in JSON-API. No time zone is inferred for events
with inferred times, as two guesses would pin them to a time and day that may not apply; their floating exports
already show on the right day.
Advice only.
Motivation and context
See #1391. On tess.elixir-europe.org, 191 of 231 upcoming events have no time zone, all of them ingested, so their
times cannot be placed.
Question
wheretzbundles the boundary polygons (151 MB in the image; last released 2021). Acceptable, or would youprefer the
timezonegem with GeoNames (account, network calls), or a less exact lookup withtzinfoalone(wrong near zone borders)?
Existing events need no migration: all events without a time zone on tess.elixir-europe.org are ingested, and the upcoming ones get their time zone inferred, or their times marked as inferred, when their source is next ingested.
Screenshots
Checklist
🤖 Generated with Claude Code