José, let me just qualify the intent of the Calendar struct and its
supporting cast of friends in Date, Time, .... there seems to be
assumptions in some areas that the date tuple {y, m, d} is always the same
encoding of a date. For example in Date.compare:
@spec compare(Calendar.date, Calendar.date) :: :lt | :eq | :gt def compare(
date1, date2) do case {to_erl(date1), to_erl(date2)} do {first, second} when
first > second -> :gt {first, second} when first < second -> :lt _ -> :eq end
end This assumes that the date encoding has the same meaning across
calendars and that the {y, m, d} are always ISO representations (or at
least the same representation) (a) Is the design intent that all Calendars
use the {y, m, d} to represent an ISO date and therefore internally convert
when required? (b) Calendars are free to use {y, m, d} for different
non-ISO encodings and therefore
Date.compare and others should be adjusted to be calendar agnostic?
On Monday, December 19, 2016 at 7:32:16 PM UTC+11, José Valim 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
> Skype: jv.ptec
> Founder and Director of R&D
>
> On Sun, Dec 18, 2016 at 10:30 PM, Kip <[email protected] <javascript:>>
> 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. 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
>>> 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] <javascript:>.
>> 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.
>>
>
>
--
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/69b007bf-4253-4292-828d-75ea5b499358%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
