Skip to content

Correctly handle ISO reference year for MonthDay #412

Description

@Manishearth

https://tc39.es/proposal-temporal/#sec-temporal-calendarmonthdaytoisoreferencedate

  1. Return an implementation-defined ISO Date Record, or throw a RangeError exception, as described below.

Currently we return (iso era, 1972) for all calendars.

I'm not quite sure what we ought to do here.

Activity

  1. added this to the 0.0.12 milestone on Jul 22, 2025
  2. Manishearth commented on Jul 23, 2025

    @Manishearth
    ContributorAuthor

    I think the standard ought to specify a default Temporal year, much like it specifies a default Temporal epoch

    cc @sffc

  3. Manishearth commented on Jul 23, 2025

    @Manishearth
    ContributorAuthor

    We also have this issue:

    // TODO: This may get complicated...
    // For reference: https://github.com/tc39/proposal-temporal/blob/main/polyfill/lib/calendar.mjs#L1275.
    Err(TemporalError::range().with_message("Not yet implemented/supported."))

    @nekevss the line number for that link has changed; is there something subtle we need to worry about?

    I wonder if there is sensible default behavior we can pick here that works for all calendars while we wait for official word from the spec? Curious if @sffc has thoughts.

  4. nekevss commented on Jul 23, 2025

    @nekevss
    Member

    Huh, I'm not remembering the exact point on that file.

    There wasn't anything particularly subtle being noted. It was mainly the amount of month focused methods involved in non-ISO calendars.

  5. Manishearth commented on Jul 23, 2025

    @Manishearth
    ContributorAuthor
  6. modified the milestones: 0.0.12, 0.0.13 on Aug 4, 2025
  7. Manishearth commented on Aug 10, 2025

    @Manishearth
    ContributorAuthor

    We now handle most of these according to the spec algorithm except for Chinese/Dangi. I'd like to wait for unicode-org/icu4x#6800 before attempting Chinese/Dangi.

  8. sffc commented on Aug 12, 2025

    @sffc
    Contributor

    Thought: with the proleptic approximation, we can choose years far in the past and fully cover the 30-day leap months.

  9. Manishearth commented on Aug 12, 2025

    @Manishearth
    ContributorAuthor

    @sffc My understanding is that most attested Chinese tabular (algorithmic) calendar approximations like pingqi apparently don't cover all leap months. I can't remember my source on this, unfortunately.

    I know that Le calendrier chinois: structure et calculs has details on this, I'll check it out later.

    It's worth considering: we have an aversion to using out-of-range dates (I certianly do!) but the actual reference year for MonthDay doesn't really matter: it only shows up when formatting in strange scenarios, I think. So we might be fine using something far out of range.

  10. Manishearth commented on Aug 12, 2025

    @Manishearth
    ContributorAuthor

    Dans la haute antiquité en effet, le mois intercalaire semble parfois avoir été placé systématiquement après le douzième mois, en queue d'année lunaire. De la vingtsixième année des Qin (1"V221) à I"VI04, il aurait continué d'occuper une place de rang fixe, mais pas la même qu'auparavant puisqu'il aurait été rangé juste après le neuvième mois et se serait alors appelé hou jiu yue i&fLftf (neuvième mois postérieur 25).

    Le calendrier chinois: structure et calculs p70

    it's basically saying that older calendars would fix the leap month e.g. at the end of the year.

  11. sffc commented on Aug 12, 2025

    @sffc
    Contributor

    The reason we don't have very many leap months in the winter is because the solar terms are shorter in the winter, so it is less likely for there to be a lunation without a major solar term. But, the pínqì approximation makes the solar terms a fixed length, meaning that there should be an equal number of leap months in the winter as in the summer, especially if we use a mean synodic month for the lunar cycle.

  12. Manishearth commented on Aug 13, 2025

    @Manishearth
    ContributorAuthor

    @sffc Yeah, I think what's going on is that this is highly dependent on the choice of proleptic approximation; some evenly distribute leap months, others only put them at certain points of the year.

    If we wish to use a proleptic approximation that was in historical use, we may be stuck to ones that are less flexible. But we don't have to, if pinqi gets us that behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    blockedWaiting for some code change

    Type

    No type

    Projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions