My first crate - SAC13, calendar reform proposal

code review
1

Hello everyone,

I recently published my first crate sac13. It's the reference implementation for a calendar reform proposal "SAC13" (long story; sac13.net).

I'd love to get some feedback, on my Rust code (you can find it on Codeberg here: SAC13/sac13.rs - Codeberg.org), the project setup, code comments/documentation and code organization.

Here are some questions I'm particularly interested in:

  • How far should I go to make "invalid state unrepresentable" (for example my NonZeroU8 uses)?
    • Or is that too much and just hurts usability?
    • Or should I go even further, for example for numbers with specific ranges (for example, unrelated to the project, a custom datatype to represent just the numbers 1-6 for a die)?
      • Examples in the code, would be the types created with the scalar! macro.
  • Are the macro usages in raw_date.rs okay or too much?
  • Is the test organization okay? Currently I try to keep most tests as close as possible to the code that's tested, but I saw some projects where tests are all in a completely separate module (at root level)

I want to thank everybody that takes a look in advance for their time and effort. Thank you. Depending on the kind of feedback you are welcome to directly open issues on Codeberg or just leave a comment here.

You are of course also welcome to critique the calendar proposal itself, the website, or my English (not my first language), even though my main intention is getting feedback on my Rust code.

1 Like
2

It looks cool in my opinion. I published dozen crates, but still can't program on your level. My only one concern is - why do you consider that your user speak English?

3

Thank you very much for your time and your comment.

I thought about leaving that function out but I kept it because the wasm module on the website which is used for the "Try it!" calculator uses that.

I typically try not to assume that everyone speaks English. The only alternatives in that case would be to

a. not have that function (I could move if closer to the where it's actually needed - the calculator)
b. provide translations for many languages, which I really try to avoid because that's hard to get right and maintain.

1 Like
4

SAC13 is an interesting idea.

But why oh why move the new year well into spring time? I would much prefer New Year to be at the winter solstice.

5

There are a few reasons why I chose it (some are mentioned on sac13.net as well):

  • It's the only reasonable option if we want to
    1. Keep the new months close to the Gregorian months (unlike other proposals that just shift the months so they wouldn't make intuitive sense any more to people already used to Gregorian Calendar months)
    2. Fix the ordinals September - December
  • Before the Romans changed it for political/warfare reasons in 153 BC the year started with March (back then the numbering September - December) still made sense.
  • The March equinox (northward equinox) is a scientifically important reference point.
    • Between the two equinoxes it's just convention/historical that the northward equinox was picked instead of the southward equinox.
    • The equinoxes are historically more important because solstices were (and to some degree still are) harder to measure because the apparent position of the sun doesn't change much at that time, so it's harder to figure out when the turning point was exactly
      • It's a bit like throwing a ball in the air. It's simpler to exactly time-stamp (e.g. with a high speed camera) when the ball hits the ground vs when the ball is at it's peak.

If one really wanted to start the year with the winter solstice one would have to (probably, I never simulated it) slightly change the leap year rule and find new names for all the months (to fix the ordinal misnomers and to prevent confusion because of shifted months)

6

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.