Build a date from a flat, epoch-relative day count (the calendar's own epoch).

Extract the flat, epoch-relative day count from a date.

Decode a date to (year, zero-based month, day-of-month). The year is signed so calendars can represent pre-epoch (e.g. BC) years without wraparound.

Lens for the day component of a HasDate. Please note that days are not clamped: if you add e.g. 400 days then the month and year will roll

Accessor for the Month component of a HasDate.

Lens for interacting with the month component of a HasDate. Please note that we convert the month to an Int so meaningful math can be done on it. Also please note that the day will be unaffected except in the case of "end of month" days which may clamp. Note that this clamping will only occur as a final step, so that

>>> modify monthl (+ 2) <$> Gregorian.calendarDate 31 January 2000
Just (CalendarDate 31 March 2000)

and not 29th of March as would happen with some libraries.

Lens for the year component of a HasDate. Please note that the rest of the date is left as is, with two exceptions: Feb 29 will clamp to 28 in a non-leapyear and if the new year is earlier than the earliest supported year it will clamp back to that year

Accessor for the Day of the week enum of a HasDate, for example:

>>> dayOfWeek . fromJust $ Gregorian.calendarDate 31 January 2000
Monday

Returns a HasDate shifted to the nth next Day of Week from the current HasDate, for example:

>>> next 1 Monday . fromJust $ Gregorian.calendarDate 31 January 2000
CalendarDate 7 February 2000

Returns a HasDate shifted to the nth previous Day of Week from the current HasDate, for example:

>>> previous 1 Monday . fromJust $ Gregorian.calendarDate 31 January 2000
CalendarDate 24 January 2000

Access the year, month and day-of-month components together in a single call, returned as a (year, month, day) tuple.

This is purely an access optimization for code that needs more than one date component at once. Reading the components individually with year, month and day is perfectly correct, but for a packed representation (such as the Gregorian Date, which stores a cycle/century/day-in-century triple) each of those accessors independently decodes the stored value, so asking for all three separately decodes it three times. yearMonthDay decodes once and hands back every component, which is noticeably cheaper on hot paths (for example date formatting). For representations that already store the components separately (such as the Julian Date) there is nothing to decode and this is simply the three field reads, so it is never slower than the individual accessors and callers can use it unconditionally.