[manifoldgeo]

How does something like `let y: Time = 1 year` work? Does it take into consideration the idea of leap years and leap seconds, counting a single year as 365.2422 days[0]? Or does it count as 365 days?

I got curious and installed the CLI tool[1] and found that it does indeed account for leap second / leap years:

>>> let jahr: Time = 1 year

>>> let tage: Time = jahr -> days

>>> tage

    = 365.243 day    [Time]

References:

0: https://museum.seiko.co.jp/en/knowledge/story_01/

1: https://numbat.dev/doc/cli-installation.html

[vlovich123]

I feel like that’s unit confusion. Converting from year to day should require you to specify what calendar year you’re in to resolve the ambiguity. Otherwise I set an alarm for today + 1 year and things are off by 6 hours.

Time is nasty because there’s lots of overloaded concepts and bugs hide in the implicit conversions between meanings.

I’m also kinda curious what the underlying type is. Is it a double or do they use arbitrary precision math and take the perf hit.

[SenAnder]

> I feel like that’s unit confusion. Converting from year to day should require you to specify what calendar year you’re in to resolve the ambiguity.

A year has two meanings - a calendar year, with all the leap days and seconds and timezones, or a duration of time. The latter is still useful, e.g. when someone states that Proxima Centauri is 4.2 light-years away, they don't want to deal with leap-days.

Decent time libraries have separate ways to deal with durations and dates.

[thriftwy]

Except there is also https://en.m.wikipedia.org/wiki/Sidereal_year So I would say they need explicit different years.

[sharkdp]

So 'year' refers to the Gregorian year and is equal to 365.243 days [1]. We also have 'julian_year' which is equal to '365.25 days'.

We also have 'sidereal_day' equal to '23.9345 hours', and if you believe it is useful, we can also add 'sidereal_years'.

[1] https://numbat.dev/doc/list-units.html

[thriftwy]

Do you have a calendar_year and a calendar_leap_year?

[techdragon]

Ok so I did some reading and I like what I see, its important however to properly disambiguate between the two kinds of time units.

Chronological Time units and Calendrical Time units... These are fundamentally different concepts that overlap a lot in day to day life but when you need to ensure technical accuracy, can be very different.

- Planck time, Stoney time, Second: Unambiguously valid for both chronological and calendrical usage. Since we define everything in terms of the second anyway it's basically the centre of the Venn diagram.

- Sidereal day: It isn't a fixed value over longer periods of time, getting longer at a rate on the order of 1.7 milliseconds per century [1], so a conversion of a short period like 7 sidereal days into seconds is going to be off by something like 3.26×10^-7 seconds which might be ok, particularly if you also track the precision of values to avoid introducing false precision in the output, since you can then truncate the precision to above the error margin for a calculation like this one and treat it unambiguously as valid for both calendrical and chronological purposes.

- It's also worth noting since you mentioned it, the slight difference between Tropical year (seconds the earth takes to do a complete orbit around the sun), and Sidereal Year (seconds for the sun to fully traverse the astronomical ecliptic), the sidereal year is longer due to the precession of the equinoxes.

- Minute, Hour: These can vary in length up to a second if a leap second is accounted for, so while conventionally fine for chronological calculations as fixed multiples, don't have precise chronological values when used with calendar calculations. The exact number of minutes between now and 2030 is fixed, but the number of seconds in those minutes is not.

- Day: In addition to leap seconds, the length of a calendar day also have to deal with the ambiguity of daylight savings time and are where the significant differences in calendrical calculations vs chronological calculations really start to kick in.

- Week, Fortnight: all the problems of days but magnified by 7 and fourteen respectively. Also, theres the concept of standard business weeks and ISO week calendars, where some years wind up with more weeks than others due to the ISO week related calendar rules.

- Month: Obvious problem... "which month?" theres quite a few less seconds in February than in October.

- Julian year, Gregorian year: These are conventionally defined by how many days they have and the leap day rules and then approximated to an average seconds value so you can "pave over" the problem here and a lot of people might not be as surprised as if you average the length of a day or a month.

- Decade, Century, Millennium: are all affected by leap day related rules, and over a given length of time you see the introduction of an unknown but sort of predictable number of leap seconds. So while you can average it down yet again, the problems of anything bigger than a day have reached the point where over a millennium you're dealing approximately 0.017 seconds of change in the rotation of the earth,

Doing this right is basically incompatible with doing this the easy way, I'd at least re-label the averaged time units to make the use of average approximations more obvious, and ideally I'd split the time types into calendrical and chronological, and use more sophisticated (and I'll be the first to admit, annoying to implement) calendar math for the chronological calculations.

[1] - Dennis D. McCarthy; Kenneth P. Seidelmann (18 September 2009). Time: From Earth Rotation to Atomic Physics. John Wiley & Sons. p. 232. ISBN 978-3-527-62795-0.

[joshuanapoli]

The entire type system needs to be parameterized by the inertial frame of reference, too.

[agalunar]

365·243 ought to be 365·2425 exactly:

Per 400 years, there is one leap day every 4 years (100 leap days), except when the year is divisible by 100 (so we overcounted by 4 and there are 100 – 4 = 96 leap days), except when the year is divisible by 400 (so we need to add that day back and arrive at 100 – 4 + 1 = 97). This gives us 97/400 = 0·2425.

The tropical year is about 365·24219 days long, but that's not relevant to timekeeping.

[sharkdp]

> 365·243 ought to be 365·2425 exactly:

Yes. This is also how it is defined: https://github.com/sharkdp/numbat/blob/ba9e97b1fbf6353d24695...

The calculation above is showing a rounded result (6 significant digits by default).

[agalunar]

That's what I figured! but thought the derivation would be fun to share with people reading the comments.

[peheje]

Just a fun related video from Neil deGrasse Tyson https://youtu.be/mKCvqzCrZfA?si=uW4FOXg2nrqic1ZP