José,
> Although the year starts on July 1st, we still only increase the year from
> Dec 31st -> Jan 1st, correct?
is a good example, because it refers to `year` in two ways: the `year` element
of the struct, and the name given to a year. If the year in a fiscal calendar
starts on July1st 2016 then that year would, for Australia, be called the 2017
financial year because it ends on June 30 2017. Similar idea in the US for a
fiscal year starting on April 1st. After all a {y, m, d} tuple is just one way
of encoding the progress of days and years - not all calendars use it (such as
the Balinese calendar, or the Mayan calendar). However since many (most?)
calendars in common use can be encoded in {y, m, d} the encoding mechanism is
fine.
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. The standard is a little fuzzy on this topic and
which is why I think it may have been preferable to call the default
implementation Calendar.Gregorian since day 1 of week 1 is the same of day 1 of
the year.
The second part depends I suppose on the planned evolution of the Calendar
behaviour. For example, the behaviour includes `last_day_of_month`. For the
current implementation the assumption is that the calendar is gregorian because
the return is an integer day number. 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. 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.
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.
Arguably the better encoding of an arbitrary day in time is simply an integer
offset since some epoch - this is the approach taken by Reingold and Dershowitz
and it makes date comparison and calculation much easier. But of course its
not a familiar encoding and it needs math to convert too/from any input/output.
And given the Calendar API is published probably not of interest to you and
the team to change. It would be an analogy to the Unix timestamp so not
completely unreasonable I suppose (but it would need a different epoch than Jan
1 1970).
—Kip
> On 19 Dec 2016, at 7:31 PM, José Valim <[email protected]>
> wrote:
>
> Kip, I am not sure what would be the best way to design this system. Although
> the year starts on July 1st, we still only increase the year from Dec 31st ->
> Jan 1st, correct?
>
> So if you concern is more about week numbers and similar, couldn't it solved
> by a set of auxiliary functions that receives datetimes instead of trying to
> build new datetimes?
>
> José Valim
> www.plataformatec.com.br <http://www.plataformatec.com.br/>
> Skype: jv.ptec
> Founder and Director of R&D
>
> On Sun, Dec 18, 2016 at 10:30 PM, Kip <[email protected]
> <mailto:[email protected]>> wrote:
> The introduction of the Calendar types and the %Calendar struct is really
> helpful. Its also helpful that the @behaviour doesn't enforce using the
> struct..
>
> In several industries the idea of an annual calendar has either a fixed
> starting date or has a "day of week" starting date. For example, a calendar
> may have a year defined as "starts on the last Friday of June" or "end of the
> last Tuesday in December". Or more simply "Starts on July 1st". Whilst it
> would be possible to define a Calendar module for each of the possible
> variations it quickly becomes impractical. They are more akin to
> configuration to be applied in the context of a module that handles, for
> example, My.Calendar.FourFourFive or My.Calendar.FiscalYear.
>
> Even the Calendar.ISO module in Elixir has some ambiguity since ISO 8601
> defines an "ISO week number" (the week with the first Thursday in it) whereas
> a Gregorian calendar would assume that the first week starts with January
> 1st. Maybe thats more a naming issue than configuration but configuration
> could also help here.
>
> Therefore I wonder if the Calendar struct itself would benefit from having a
> `meta` element with default `nil` that Calendar authors could use for
> configuration information. For my simple example, My.Calendar.FiscalYear
> might use it to store `%{starts: {7, 1}}`. `For My.Calendar.FourFourFive`
> is might be `%{starts: :last:, day_of_week: 5, month: 6}`
>
> Benefits:
> A Calendar strategy can be build for a class of calendar types commonly in
> use and configuration is passed around at the same time as the Calendar
> Module name
>
> Downside:
> Duplication of configuration in potentially lots if places.
>
> Perhaps there is another approach for managing configuration? Passing around
> the Module name is of course cheap since its just an atom. Arbitrary
> configuration potentially is much more overhead depending on the content.
>
>
>
>
> On Tuesday, March 15, 2016 at 11:28:31 PM UTC+11, José Valim wrote:
> Hello everyone,
>
> I am glad to say we are introducing Calendar types into Elixir to make
> integration between all the different libraries simpler. You can see the PR
> here: https://github.com/elixir-lang/elixir/pull/4383
> <https://github.com/elixir-lang/elixir/pull/4383>. Feedback is welcome
> regarding the struct definitions.
>
> In the following months, we will be augmenting those modules and adding some
> basic functions. Although expect the heavy work, specially if it comes to
> timezone support and more, to be done in the separated libraries.
>
> Thank you!
>
>
> José Valim
> www.plataformatec.com.br <http://www.plataformatec.com.br/>
> Skype: jv.ptec
> Founder and Director of R&D
>
> --
> 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]
> <mailto:[email protected]>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/e51829a8-918c-489b-8a29-e85c7f1d79e5%40googlegroups.com
>
> <https://groups.google.com/d/msgid/elixir-lang-core/e51829a8-918c-489b-8a29-e85c7f1d79e5%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
>
> --
> 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
> <https://groups.google.com/d/topic/elixir-lang-core/KvJQaUcUlOk/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to
> [email protected]
> <mailto:[email protected]>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JFDdtYXWPiHhTqRhpybS3T_D2_HjjEgjUKtzjnHcS2AA%40mail.gmail.com
>
> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JFDdtYXWPiHhTqRhpybS3T_D2_HjjEgjUKtzjnHcS2AA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout
> <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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/1E22DAD6-3B30-4333-B637-965C39BD3EE8%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
