Repository navigation
Add REZonedDateAndTime: a local time in a time zone - #5
Merged
Merged
Conversation
A wall-clock time and the id of its zone, as RFC 9557 writes it: 2026-11-09T09:00:00+01:00[Europe/Berlin]. The offset is not stored but worked out when the moment is asked for, from the zone database that ZTimezone reads -- +01:00 in winter, +02:00 in summer -- so the value stays right when a zone's rules change. It does no arithmetic of its own: adding days to a DateAndTime keeps its offset and lands an hour off across the change to summer time. Local times that are not one moment are read as RFC 5545 reads them: a time the clock jumps over takes the offset before the jump, a time that comes twice is the first of the two, unless an offset given with it picks the other. ZTimezone alone answers the later of the two for the second case, so the choice is made here. This is the anchor a recurrence will carry, the way DTSTART carries TZID; the expressions themselves stay rules over calendar days. The central scheduler needs it to compute recurring schedules in the zone they were made in. RecurringEvents-Core now requires ZTimestamp, with the same spec ApptiveScript uses, so an image that loads both asks for one. RecurringEvents-Tests 149/149 in pharo-c, 11 of them new. Choosing the smaller of two offsets fails the test for a time that comes twice. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
A wall-clock time and the id of its zone, as RFC 9557 writes it: 2026-11-09T09:00:00+01:00[Europe/Berlin]. The offset is not stored but worked out when the moment is asked for, from the zone database that ZTimezone reads -- +01:00 in winter, +02:00 in summer -- so the value stays right when a zone's rules change. It does no arithmetic of its own: adding days to a DateAndTime keeps its offset and lands an hour off across the change to summer time.
Local times that are not one moment are read as RFC 5545 reads them: a time the clock jumps over takes the offset before the jump, a time that comes twice is the first of the two, unless an offset given with it picks the other. ZTimezone alone answers the later of the two for the second case, so the choice is made here.
This is the anchor a recurrence will carry, the way DTSTART carries TZID; the expressions themselves stay rules over calendar days. The central scheduler needs it to compute recurring schedules in the zone they were made in.
RecurringEvents-Core now requires ZTimestamp, with the same spec ApptiveScript uses, so an image that loads both asks for one.
RecurringEvents-Tests 149/149 in pharo-c, 11 of them new. Choosing the smaller of two offsets fails the test for a time that comes twice.