Using Gregorian Year vs using Mean Tropical Year

Question

I was working on a small CLI tool to convert between time units and seconds.

Someone filed an issue about how the code was treating a year as 365.25 days while the Gregorian year is supposed to be 365.2425 days, where 'day' is defined as 86,400 SI seconds.

Upon further research, I stumbled onto the concept of mean tropical year which at 356.2422 is touted as a "true year" (whatever that means).

Which definition of "year" should I incorporate? Which makes the most sense and is least likely to surprise the user?

Answer 1

If you are going to write a generic tool conversion which might be used in different contexts, and you don't know the precise use cases for which the tool will be used (or you expect different groups of users to have different requirements), your best bet is to provide different conversion options. Then each user can pick the option which suits them most.

In case of time conversion from seconds to years, I can imagine more than just the three different cases you already mentioned:

• I can imagine contexts where the approximation "year = 365 days" is totally sufficient and may meet the user's expectations most, for the ease of use

• I can imagine contexts where the conversion should get a reference date where the number of seconds should be added to or subtracted from, and leap years must be taken into account (and/or leap seconds)

As to which of the different options to pick as default: this is where you really have to ask some of your users, or put some of your general knowledge about your user base into it. There is no "generally best" approach here, and none which strangers from the internet know better than you. However, if you already released a version with a specific length of the year, it is often best when you keep that length to be the default, for not breaking backwards compatibility.

Answer 2

In short

Calendars and durations are abstractions that considerably simplify the astrophysical reality. Whenever you try to match both, you’ll have to deal with inconsistencies.

Whatever year duration you’ll chose, you may dissatisfy users, and the best option is to provide free choices to cover most of the needs.

More details about issues

Using 365.25 or 365.2422 days or any other approximation will give you anyhow an unsatisfactory answer:

• For business people a year is 365 days except on leap years where it’s 366.
• For people who need the precision of atomic clocks, you should not forget the leap second to add or remove from time to time, which shofs that any two digit approximation you’ll use you face problems.
• For astrophysicians, the real duration of years is affected by variations of the rotation spead of Earth
• For all these people, floating point arithmetic will introduce additional rounding issues.

Moreover, another nasty issue is the alignement of duration with expectations regarding calendar calculations. A nasty example: The difference between October 4, 1582 and October 15, 1582 seems to be 11 days, whereas in reality it was only 86 400 seconds.

Suggestions

1. You can keep your tool like it is and document that it is based on an average.

2. You can enrich your tool by providing three options to address the most common needs/expectations:

   • business year: using 365 days, and adding an extra day every 4 years)
   • average calendar year: using 365.25 days (effects noticeable for periods larger than 400 years)
   • mean tropical year (can you call it astronomical year?)

3. The transformation is always approximative if it needs to be related to a calendar (work schedules, project management, …). Accuracy is possible only if you know the start or the end in the calendar, of the duration expressed in seconds. You could therefore think of a "high precision" mode, but its algorithm would be calendar based and very different from what you currently do. Maybe for your next tool?

4. Add a warning that your tool will not work on another planet ;-)

Answer 3

You would undoubtedly be opening a can of worms with this.

One thing to note is that "seconds" in modern usage are not necessarily reconcilable with "days" (i.e. there is not a monotonic relationship).

Calendars

In calendar-keeping, the fundamental cycle is the natural day - that is, a natural day is the time taken for a sundial (in some fixed place) to return to the same indication following a setting and re-rising of the sun. This approach exists almost universally across cultures, and has done since time immemorial.

This natural day is not the same as 86,400 seconds (as reckoned today, see below), and it's not the same as a 360-degree rotation of the Earth.

The main challenge in calendar-keeping is reconciling the natural day with (what I'll call here...) the "natural year". A natural year is not a 360-degree rotation of the Earth around the Sun. It is a return of the Earth's axis to the same phase of inclination in relation to the Sun (again, this can be measured by sundial-like means).

A natural year does not consist of a whole number of natural days, and in fact the fractional part is not even stable over time.

Instead conventions are used. In the Julian calendar (in use 45BC to 1582 in the Roman-Catholic world generally, and until 1752 in the English-speaking world), the convention is that a year consists of 365.25 days.

In the Gregorian calendar (in use 1582-present in the Roman-Catholic world generally, and 1752-present in the English-speaking world), the convention is that a year consists of 365.2425 days.

As you say, the astronomical reality at present is something like 365.2422.

Clocks

Historically, the natural day was divided into "hours", typically as measured by a reading from the sun using a sundial. These hours were originally not necessarily 1/12th equal parts of the day - for example, seasonal variation away from the equator means day-time and night-time varies in length, and therefore the hours themselves vary in relative length.

Later on when machinery became better at measuring and keeping time, there were further divisions into minutes (1/1440th of a day) and eventually seconds (1/86,400th of a day).

Finally in the 20th century, seconds stopped being defined in terms of the natural day (i.e. in terms of any astronomical phenomena) at all. Instead, modern physics defines a second purely in terms of the progression of a network of atomic clocks on Earth.

In this scheme, the "atomic second" is the master quantity, and a natural day does not automatically consist of a fixed number of atomic seconds (as it did when a second was defined as a division of a natural day).

There are then two main schemes to reconcile atomic seconds with the concept of days.

There is UTC, which consists of the definition of an "atomic day", which consists of a multiple of atomic seconds, and with the ad-hoc insertion of "leap seconds". These leaps keep the natural day aligned with the atomic day, so that in general UTC stays aligned with the astronomical reality. The disadvantage is that there is no predictable scheme for when leap-seconds will occur - and any given atomic day does not consist of a fixed number of atomic seconds, in the UTC scheme.

Then there is TAI, which effectively discards the concept of the natural day completely, and simply substitutes the atomic day (and the atomic month, and atomic year) which are multiples of atomic seconds as measured by atomic clocks. This has no direct connection to astronomical phenomena at all, but it has a consistent pattern of progression.

Conclusion

The vast majority of programmers, let alone "users", have little grasp of the complexities in this area.

One of the main challenges is that modern clocks measure atomic phenomena, not astronomical phenomena.

There is no single approach that would satisfy any potential user.

A good proportion of the world cannot tell you the Gregorian rule for leap-years - I assume that is why you got that bug report about treating the year as 365.25 days.

Fewer still understand the leap-second system for UTC, and even most software packages behave in practice more like TAI when performing arithmetic with dates and times.

I would drop the idea of any general-purpose converter.