Can you please specify which functions would you like to add to Calendar? first_week(year, month, day) and last_week(year, month, day)? Or is it first_week(year) and last_week(year)?
*José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D On Fri, Jul 14, 2017 at 3:53 PM, Kip <[email protected]> wrote: > @jose, @Qqwy, > > I am prototyping some of these implementation details in the next release > of my CLDR work. The nature of a week is indeed a complex beast. But > since José was smart enough to pick ISO calendar as the Elixir > implementation the definition of "first week" seems clear. The first week > is that in which the first Thursday falls. (or is the that week with at > least 4 days of the new year). > > Before I get too far may I ask if this is in agreement? The reference I > am using is https://en.wikipedia.org/wiki/ISO_week_date#First_week with > the suggest calculations being https://en.wikipedia. > org/wiki/ISO_week_date#Calculation > > For other calendars the definition of "first week" is/may be territory > specific. As is "first day" and "weekday". Which is why localisation is > such fun ...... > > --Kip > > On Tuesday, July 11, 2017 at 3:53:36 PM UTC+2, Wiebe-Marten Wijnja wrote: >> >> Yes, I think those arguments are arguments for allowing weeks to be >> specified in their own calendar implementations, treating weeks like months. >> I'd think Elixir itself should then implement the ISO week date calendar, >> and locale-specific week logic can be put in locale-specific calendar >> implementation modules. This would also keep the door open for "4-5-4" and >> friends-based weeks, 10-day based weeks, etc. >> Counting in weeks definitely has the same amount of complexity as >> counting in months in a normal calendar (I am talking about odd leaping >> rules here), so it definitely makes sense to use the same or a similar >> interface for this. >> >> The question then remains to how to make this more user-friendly. Maybe >> we can add functions on the `Date`-module that take an optional >> `week_calendar: Calendar.Implementation` as last parameter, that underwater >> does: >> >> 1. Take the Date-struct, and convert it to the given Calendar. (failing >> as usual if the conversion is not possible because of incompatible >> calendars) >> 2. Perform calculations on the resulting struct using the existing >> Calendar implementation functions, where the 'months' are weeks. >> 3. Return the desired answer. >> >> >> On Monday, July 10, 2017 at 11:48:26 PM UTC+2, Kip wrote: >>> >>> Definitely worth thinking about as an approach for weeks. Some of >>> calendars may make that tricky - I'll need to ponder some more. >>> >>> 1. "4-5-4" calendar (and its related friends 445 and 544). This is >>> used extensively by the retail industry (https://nrf.com/resources/4-5 >>> -4-calendar). >>> >>> 2. Another class is the financial period calendars of corporations in >>> the US that get to define their fiscal year. For example Cisco Inc has a >>> financial year defined as "ends of the last Saturday of July". Its fiscal >>> year 2017 for example, starts on July 31st 2016. (also to note the >>> effective year is different from the gregorian year of the day in >>> question). This is a class of calendar that requires configuration >>> information - I haven't quite worked out the right strategy for these >>> calendars yet (Date.new/3 won't fit these cases as is) >>> >>> Then there is the locale-specific understanding of a week: >>> >>> 1. Starts on a Monday, Saturday or Sunday >>> >>> 2. 1st week starts as the first calendar week which contains four days >>> of the new year >>> >>> 3. 1st week starts as the week in which January 1st occurs >>> >>> I think these situations are likely to make basing weeks along the ISO >>> Week strategy a bit tricky. >>> >>> On Tuesday, July 11, 2017 at 5:15:37 AM UTC+8, Wiebe-Marten Wijnja wrote: >>>> >>>> I am all for this! >>>> >>>> However, I do have a note about the week-related stuff: >>>> On one hand, people might expect 'weeks' to be readily available >>>> (`:calendar` offers them, and many other libraries in other language >>>> environments do). >>>> On the other, many calendars do not themselves have a notion of weeks. >>>> (Weeks are only secondary units of date measurements (years, months, days >>>> are the primary ones) and nearly all calendars, all across the globe, use a >>>> seven-day week. >>>> Weeks are basically the months of the ISO week date calendar: >>>> https://en.wikipedia.org/wiki/ISO_week_date >>>> I wonder how much of the week-related functionality could be defined by >>>> just taking a date (in e.g. Calendar.ISO) and converting it into the ISO >>>> week date calendar. >>>> >>>> ~Qqwy/Wiebe-Marten >>>> >>>> >>>> On Monday, July 10, 2017 at 9:03:53 AM UTC+2, Kip wrote: >>>>> >>>>> With the new capabilities of Calendar in 1.5 I am now adding date and >>>>> time localisation to a package I maintain ( >>>>> https://hex.pm/packages/ex_cldr). >>>>> >>>>> CLDR (http://unicode.org/reports/tr35/tr35-dates.html#Date_Format >>>>> _Patterns) defines a number of symbols to aid formatting and >>>>> localisation. Many of these can be supported by the Calendar module (or >>>>> easily derived). Some would be better defined in a calendar module - >>>>> which >>>>> would imply adding them to the behaviour and to Calendar.ISO. >>>>> >>>>> These functions are: >>>>> >>>>> 1. months_in_year(year) which together with the existing >>>>> days_in_month/2 would allow the calculation of quarters which is relevant >>>>> in a lot of business contexts >>>>> 2. week_of_year(date) which returns the week number within which the >>>>> date occurs. >>>>> 3. week_of_month(date) which returns the week of the month within >>>>> which the date occurs >>>>> 5. day_of_week_in_month(date) returns the ordinal day (i.e. 2nd in 2nd >>>>> Wednesday in July) >>>>> 6. year(date) which returns the effective year in which the date >>>>> lies. For example in an ISO Week implementation, the "year" may be >>>>> different to the "year in the date" >>>>> >>>>> Although my immediate focus is date formatting and localisation, these >>>>> functions are of themselves relevant for other "calendarists" (is that a >>>>> word?) Each of these may have quite specific implementation details >>>>> related to a given calendar and therefore would seem to be appropriate to >>>>> be part of the behaviour. >>>>> >>>>> I've tried to think of only those functions which cannot be readily >>>>> derived without knowledge of the specific calendar but I know this is a >>>>> slippery slope - especially with anything to do with time and dates. >>>>> >>>>> Thoughts? >>>>> >>>>> --Kip >>>>> >>>>> -- > 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/56690dd1-c89b-4e28-963a- > fcd54c72494b%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/56690dd1-c89b-4e28-963a-fcd54c72494b%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/CAGnRm4JTZ7nvrc4R1ZwvAE1_ffPW-QsCew4%2Bn0rVJabwCiGQPg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
