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]> 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]. > 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/CAGnRm4JFDdtYXWPiHhTqRhpybS3T_D2_HjjEgjUKtzjnHcS2AA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
