Research on time units like "month" and "year"

[eminence]

Currently, time units like "month" and "year" are defined like this:

• 1 month = 0.0833333 year
• 1 year = 365.243 day

These are perfectly fine definitions, but may be a little unexpected in some cases (like when adding "1 year" to a date).

It would be good to know if/how other tools represent these ambiguous units. This discussion thread will be used to collect and report on this data.

For context, see #287

[eminence]

GNU units

GNU Units has a similar definition for "month" and "year" compared to numbat, but not exactly:

• 1 month is 30.43685 days (compared to numbat's 30.4369 days)
• 1 year in 365.2422 days (or 31_556_926 seconds), compared to numbat's 365.243 days (or 31_556_952 seconds)

These appear to be small rounding differences.

GNU Units has no support at all for datetimes, as far as I can tell

Qalculate

Qalculate is also similar to numbat, but uses the Julian year by default (whereas numbat uses the Gregorian year)

• 1 month is 30.4375 days
• 1 year is 365.25 days (1 Julian year)

It has functions to parse and manipulate date times. For example, it can do leap-year-aware calculations like:

> addDays("2024-02-28", 1)

  addDays("2024-02-28", 1) = "2024-02-29"

It also has a dedicated addMonths function which seems to try to be somewhat intelligent. It doesn't simply add a fixed number of seconds.

addMonths("2024-01-01", 1) = "2024-02-01"

addMonths("2024-02-01", 1) = "2024-03-01"

addMonths("2024-01-31", 1) = "2024-03-02"

addMonths("2024-01-31", 2) = "2024-03-31"

It also uses this same intelligence with the infix addition operator, but this can yield some surprising results:

> x

  x ≈ "2024-01-24T15:30:10"

> x + 1 month

  x + (1 month) ≈ "2024-02-24T15:30:10"

> x + (1 month + 0 seconds)

  x + ((1 month) + (0 second)) ≈ "2024-02-24T02:00:10"

> 1 month -> seconds

  1 month = 2629800 s

> x + 2629800 s

  x + (2629800 seconds) ≈ "2024-02-24T02:00:10"

[sharkdp]

Thank you for researching this. Just a quick comment on the different values of days ins a year. There is the (historical) Julian year with 365.25 days — one leap year every four years, but no further corrections (365 + 1/4 = 365.25). And then there is the Gregorian year (our standard calendar today) which has 365.2425 days due to additional corrections: a leap year every 4 years, but no leap year every 100 years, but a leap year every 400 years (365 + 1/4 - 1/100 + 1/400 = 365.2425).

Numbat supports both: julian_year is the Julian year and year is the Gregorian year. It displays the Gregorian year as 365.243 days, but that's just it's usual "six significant digits should be enough for everyone" behavior (which we should definitely change, because it confuses users all the time). The internally used precision is much higher. It's just when we display numbers.

[eminence]

Thanks for your comment! I've edited my post with some of the info you provided

[sharkdp]

Frink

Frink has an excellent documentation on this topic. It's worth a read, but to summarize the main points that are useful for us at the moment (in relation to #287):

• year in Frink is the "tropical year", which is slightly different from the Gregorian year (~365.2422 vs 365.2425). This might be the better default, especially for astronomical calculations. But the difference is not relevant for the discussion in Initial support for DateTime types #287. I just now noticed that GNU units also uses the tropical year instead of the Gregorian year.
• month is 1/12 of that (which is the only reasonable option I believe)

Syntax

Frink has a nice shortcut syntax for entering dates, using #…# separators. We can't use the exact same syntax (because # is reserved for comments), but doing something similar looks like a good idea to me.

Date-time arithmetic

Involves the usual operations: "You can subtract one date from another, or add/subtract a time interval to a date."

Adding time intervals to dates: the Frink documentation has this paragraph which summarizes the concerns we had in #287:

Note: You may notice that adding units of months or years (or commonyear, etc.) may not give you the results you expect--that is because months and years are not fixed-size units, and even having a unit called "month" or "year" is inherently ill-advised.

So you can do things like #2024-02-06# + 1 year, but they result in the same "problem" that we discussed: 2025-02-05 AM 05:48:45.975 (Wed) Central European Standard Time.

Calendar functions

Frink has many functions for manipulating calendar dates, and it looks like they put a lot of thought into it. Might be worth a look once we get there.

Notably, they do not have a add_months function (and similar), because they would be ill-defined in cases like add_months(<some date like Jan 31st>, 1). Instead, they have e.g. beginningOfMonthPlus which lets you add one month, but only to the beginning of a month.

Time zones

Frink allows users to abbreviate some time zones, e.g. Paris instead of Europe/Paris. Might be something worth considering.