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?

  • 2
    In scientific contexts, the unqualified word “year”, when used a unit of time (as opposed to a calendar period), is often defined as a Julian year of 365.25 days of 86400 SI seconds. This is recommended by both the Unified Code for Units of Measure and the International Astronomical Union (which defines the “light-year” on this basis). Other scientific communities prefer the length of the tropical year in the year 2000 (31,556,925.445 seconds). See Wikipedia:Year. Jan 15 at 21:04

3 Answers 3


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.

  • This is what I have done now. In the latest commit, I've added the ability to choose from half a dozen year types at compile time, and the default is Gregorian. But adjustment for leap years based on a reference date is not a feature that I will add. It would add unnecessary complexity for marginal utility at best. Not to mention that leap seconds are insane and impossible, and all this insanity is why the tool exists - it is an aid to wean off larger units and develop intuition for thinking in SI seconds.
    – An Ant
    Jan 16 at 6:12
  • @AnAnt: not sure why you hesitate to make this a runtime feature. Would probably be more useful (but as I said, you have to know your audience).
    – Doc Brown
    Jan 16 at 7:11

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.


  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 ;-)

  • 3
    I've also seen "year" defined as "12 months of 30 days each". And of course if you define "year" as "the time from date X in year Y to the same date in year Y+1", then you have to work with things like years which are missing months, day light savings time moving around, getting introduced, or abandoned, countries moving between time zones, countries changing their calendar mid-year, leap seconds, etc. – and then there's the case where date X doesn't exist in year Y+1. Jan 15 at 11:09
  • 1
    @JörgWMittag Very valid remarks indeed, the 12x30 is popular in financial communities in some countries. However the same communities don’t work in seconds but in days. This is why I suggested to keep it simple by addressing the most popular cases. Keeping duration in sync with point of time is a very difficult exercise as your reamrk on daylight saving confirms
    – Christophe
    Jan 15 at 11:22

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).


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.


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.


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.

  • Thank you for this enlightening discussion of calendar systems, astronomical time and atomic time. I hate the rough edges and inconsistency when dealing with bigger units, and the raison d'être of the tool is to wean myself (and anyone interested) off them and into using seconds and scientific notation. The idea is to build intuition and adjust to thinking in seconds, TAI-style. So I would'nt want to "drop the idea of any general-purpose converter" and instead try to get to a reasonable approximation of the natural units.
    – An Ant
    Jan 15 at 14:57
  • 1
    I happen to work in an industry whose primary synchronization mechanism is based on TAI, precisely in order to avoid discontinuities in the presence of leap seconds. A system that a lot more people may be familiar with is GPS, which also doesn't use leap seconds (and thus doesn't use UTC) but also doesn't TAI – it uses its own GPS Time. (GPS Time and TAI are synchronous in the sense that their seconds tick at the exact same instant, but they have a fixed offset from each other. UTC ticks in sync with GPS and TAI, but its offset changes over time; currently, it is 37s to TAI and 18s to GPS.) Jan 15 at 16:51
  • @AnAnt, the problem as I see it, is that there is no single "scientific" or "natural" approach that serves all needs. You can define months and years in terms of a fixed number of seconds for each, but the immediate problem you'd have is not just that your periods wouldn't align with any existing calendar, but the start time of the day itself would vary. For example, after the second year, your "midnight" would be around high noon astronomically. Or else, the start time of months and years would vary from the start time of the day.
    – Steve
    Jan 15 at 17:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.