> This is even a small ambiguity in an ISO calendar since the question of
> “first day of the year” depends on whether you mean the first day of the
> first week, or the first day of January.
>
ISO8601 defines three representations: Calendar date, ordinal date and week
dates. We could explicitly document we are implementing the first format.
But if your calendar starts on “first thursday of april” then the last day
> can only really be encoded as {m, y} in the gregorian calendar because the
> notion of a month in this calendar does not align with a gregorian month
> boundary. I suppose that if the definition of `last_day_of_month` was
> changed to mean “number of days in a month” then this type of calendar
> could be implemented without change and still be compliant with the
> calendar behaviour.
>
If you have a calendar where the first month starts on "first thursday of
April" and finishes the first month on the "first wednesday of May" such
calendar still has a notion of months. In a leap week calendar they would
all have 28 days with the exception of a month with a leap week (which
would have 35).
Writing the paragraph above also made it absolutely clear that you are
indeed correct: days_in_month/2 is a better name than last_day_of_month/2.
Since last_day_of_month/2 was not yet released (only in RCs), I will go
ahead and rename it.
On the other hand, You could also have week-based calendars that have no
notion of months and therefore last_day_of_month or days_in_month have no
purpose. Those probably wouldn't be representable with Elixir's calendar
types.
> But I would still need some way to define configuration. How do I capture
> that my version of Calendar.FiscalYear starts on July 1st, and another one
> starts on April 1st. All other rules are the same - just a different start
> date.
>
Calendar modules are backends that power DateTime, Date, and NaiveDateTime.
This means you could have a function such as:
FiscalYear.define(MyApp.AprilCalendar, starts_at: "foo", ends_at: "bar")
The above would define a module named MyApp.AprilCalendar that implements
all of the Calendar behaviour functions. It works similarly to the metadata
you have mentioned, except such parameters are defined at compilation time,
rather than runtime.
However, it is still not clear if the above would be the preferred solution
to the problem. I am still partially inclined to think having a FiscalYear
module that works orthogonally to the ISO calendar would work best. In such
approach, you would have:
FiscalYear.define(MyApp.AprilBased, starts_at: "foo", ends_at: "bar")
That would define a module mirroring many of the functions in Date/DateTime
except they do fiscal year related manipulations. For example, you could
have Date.beginning_of_next_month(date) and
MyApp.AprilBased.beginning_of_next_month(date) and they would return
different results. The benefit is that you keep the data representation the
same and choose how you want to manipulate it.
Do you have any preferences?
> I think the idea of representing a date as a {y, m, d} is effectively an
> encoding mechanism that happens to be the same as the proleptic Gregorian
> calendar - a case which matches the calendar in use by a lot of people
> thereby making it convenient and easy and I’m not proposing any alternative
> to that.
>
Yes, we have discussed both y/m/d and second based and the consensus was
around {y, m, d} due to conversion cost and pattern matching benefits.
Thanks for the e-mails!
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JzQOf2F-sO%2BZy4dYo%2Bn-UqOph7eer5dpLqD9TxJ8brPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
