Sorry trex, we can't handle your insurance claim :(

Just having fun with Elixir and seeing this method.

:thinking: thinking would months in a year ever change… but then seeing the error playing around :slight_smile:

iex(1)> Calendar.ISO.months_in_year(1)
12
iex(2)> Calendar.ISO.months_in_year(99)
12
iex(3)> Calendar.ISO.months_in_year(3939848447)
** (FunctionClauseError) no function clause matching in Calendar.ISO.months_in_year/1

    The following arguments were given to Calendar.ISO.months_in_year/1:

        # 1
        3939848447

    Attempted function clauses (showing 1 out of 1):

        def months_in_year(year) when is_integer(year) and (year >= -9999 and year <= 9999)

    (elixir 1.11.3) lib/calendar/iso.ex:601: Calendar.ISO.months_in_year/1

This is as sepcified in ISO 8601. Extended years with more than 4 digits are not mandatory and require prior agreement with sender and receiver of the date.

In theory implementing an own Calendar.ExtendedISO which supports years with more than 4 digits should be possible and would fullfil the “prior agreement” part.

3 Likes

wow thank you! didn’t even bother looking into the ISO details. That is amazing and hilarious :slight_smile:

It therefore represents years from 0000 to 9999, year 0000 being equal to 1 BC and all others AD. However, years before 1583 are not automatically allowed by the standard. Instead “values in the range [0000] through [1582] shall only be used by mutual agreement of the partners in information interchange.”

If you are doing fossil inventory or history recording, don’t use this guy then :smiley:

Well, fossil recording would probably not use the ISO 8601 calendar but something else. That is the trick of the different calendar implementations.

TBH, tracking anything with exact date-stamps prior to the twentieth century is a bit of a minefield - the calendar in ISO8601 started being adopted in 1583 but took a looooooooong time (and a lot of politics / religion played out with swords and muskets) to be consistently adopted:

1 Like