Rename calendrical_calculations::iso to calendrical_calculations::gregorian

[robertbastian]

The book uses the term "ISO calendar" for the ISO week calendar, which is another (unimplemented) calendar.

We should follow its naming in this crate.

[gemini-code-assist]

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

[Manishearth]

I'm not really sold on this. This is one of the few modules that will get called outside of implementing that module's calendar, calling it iso (which is more accurate, and more broadly applicable) is good. The book naming is useful for verifying code correctness but I don't think we need to match it exactly. We have a fair amount of important stuff that doesn't come from the book already, like keviyah.

Furthermore, helpers like the week thing from my draft PR or the Neri/Schneider code could probably go in here.

[robertbastian]

calling it iso (which is more accurate, and more broadly applicable) is good

But it's not? ISO is a specialized Gregorian calendar and interchange format, but it's first and foremost a Gregorian calendar, and all the calculations here are general Gregorian calculations, like the calculations in the julian module are Julian calculations.

I was actually looking for Gregorian logic in this crate and couldn't find anything. It took me a while (and checking the book) to figure out that everything that is called gregorian* in the book is called iso* in our crate (while the book has iso* functions that mean something completely different).

[sffc]

I don't have an opinion unless you want me to form one

[Manishearth]

I was actually looking for Gregorian logic in this crate and couldn't find anything

I'd say the same for looking for iso logic. I'm happy with a reexport if that helps, and ensuring that the lisp method names are mentioned in the docs.

[robertbastian]

Gregorian is by far the more common name for this calendar, and if the book uses it, we should use it at least in this crate.

I honestly don't understand why we have an Iso calendar in icu_calendar at all. It's just the Gregorian calendar, it's not formattable, what's the point? The only difference is the eras, but you can always get ISO behaviour through extended_year.

[Manishearth]

We have it as a primitive, basically. And the problem with "gregorian" is that often that includes the switchover, which you really don't want to have to think about when working with an ISO datetime primitive.

Gregorian is the more used one but when writing datetime code "ISO" is thrown around a lot. The name is useful too.

I'm in favor of making this more discoverable for gregorian users, I'm against making it less discoverable for ISO users or making a breaking change. I think there's plenty of stuff we can do that satisfies both.

[robertbastian]

And the problem with "gregorian" is that often that includes the switchover, which you really don't want to have to think about when working with an ISO datetime primitive.

The only APIs that expose the year 0 difference between these calendars are year_info, which is basically only for formatting (something that ISO doesn't support) and new_from_codes where they agree on the extended year but not on the eras. Date::try_new_iso and Date::try_new_gregorian are identical APIs. Anyway, that's icu_calendar, but the book just doesn't use ISO calendar terminology outside of the ISO week calendar.

I'm against making it less discoverable for ISO users or making a breaking change

So what if we want to implement the ISO week calendar from the book? That should own the calendrical_calculations::iso namespace, including functions like fixed-from-iso etc.

[Manishearth]

The only APIs that expose the year 0 difference between these calendars

I meant gregorian-julian switchover. Just "Gregorian" is ambiguous. When implementing a Gregorian calendar, that's something you should check for and it's fine for that to be something you have to. When doing other calendrical stuff you should not have to worry about your main calendrical primitive being ambiguous.

So what if we want to implement the ISO week calendar from the book? That should own the calendrical_calculations::iso namespace, including functions like fixed-from-iso etc.

I'd call it iso_week; I'd be against using the fixed-from-iso naming anyway.

This crate is more than a wrapper around the Reingold calculations. It's mostly that, but it's more, too.

[Manishearth]

I guess my problem with this is that I think most of the current users of this API should be calling it ISO, not gregorian.

Only calendar/src/cal/gregorian.rs should call it gregorian.

Definitely the zoneinfo64 code shouldn't be calling it "gregorian"; time zone code I have seen is very consistent about using "ISO".

[Manishearth]

I'm okay with the reexport, I'm not okay with this being considered second class.

[robertbastian]

Definitely the zoneinfo64 code shouldn't be calling it "gregorian"; time zone code I have seen is very consistent about using "ISO".

zoneinfo64 should definitely call Gregorian, that's the calendar. I don't know where we got the concept of ISO as a calendar from (temporal?), but it's not universal (ICU4C/J doesn't have it).

[Manishearth]

Temporal, yes, but I've seen the notion of "ISO date" when reading standards a fair amount.