Closed sestrella closed 3 years ago
This or something like it makes sense.
Number of ways we could go with this. For example, we currently have:
type DayOfMonth = Int
pattern MonthDay :: Month -> DayOfMonth -> Day -- bidirectional
So we could do this:
type DayOfQuarter = Int
pattern QuarterDay :: Quarter -> DayOfQuarter -> Day -- bidirectional
Alternatively (or additionally), we could do:
class HasDays t where
firstDay :: t -> Day
lastDay :: t -> Day
lengthDays :: HasDays t => t -> Int
lengthDays t = succ $ diffDays (lastDay t) (firstDay t)
instance HasDays Year
instance HasDays Quarter
instance HasDays Month
instance HasDays Day
Great, thank you for the ideas, I'm going to try the first approach
Going to do QuarterDay
pattern as well I think.
OK this is done now.
@AshleyYakeley thank you for all the follow-up work renaming the type class and moving class instances close to the type definitions, I was in doubt of following that path or creating a separate Instances module like FormatTime
and ParseTime
. I'm planning to submit a PR adding some property/unit tests for those functions that have DayPeriod
as a type constraint if that is OK with you?
The addition of a module to handler quarters is very useful. As a Rubyist (and Haskeller) I like to come back to Ruby in search of features to implement in Haskell and I found the following one pretty useful:
An equivalent Haskell version would look something similar to:
I understand this is a core library and this feature might get rejected, but dealing with quarters seems like a pretty common use case. I'll be more than happy to submit a PR if this feature gets approved.
Reference