Thanks for the food for thought José. The Calendar.define() approach sounds
much better than passing a meta payload around. In some cases I can see
compile time benefit, others cases would need runtime definition but that's
workable since it still would be defined only once.
I'm going to finish up some code I've been working on and incorporate the
Calendar.define() strategy (I'll experiment with both approaches) and see if
that would be worth a PR down the road.
> On 19 Dec 2016, at 9:21 PM, José Valim <jose.va...@plataformatec.com.br>
> wrote:
>
>
>> 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 a topic in the Google
> Groups "elixir-lang-core" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elixir-lang-core/KvJQaUcUlOk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elixir-lang-core+unsubscr...@googlegroups.com.
> 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.
--
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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/42384CA7-824A-4039-9FFD-2E67E686F0F4%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
