OK, so here are the basic functions of System.Time.Calendar:
utcToCalendar :: TimeZone -> UTCTime -> CalendarTime
calendarToUTC :: TimeZone -> CalendarTime -> UTCTime
CalendarTime should be a "struct", i.e. a datatype with its constructor
and access functions exported.
Here's a "flat" definition:
data CalendarTime = CalendarTime
{
ctYear :: Int,
ctMonth :: Int,
ctDay :: Int,
ctHour :: Int,
ctMin :: Int,
ctSec :: Int,
ctPicosec :: Integer
} deriving ...
This has a certain simplicity to it.
Alternatively, there's this:
data TimeOfDay = TimeOfDay
{
todHour :: Int,
todMin :: Int,
todSec :: Int,
todPicosec :: Integer
} deriving ...
data CalendarDay = CalendarDay
{
cdYear :: Int,
cdMonth :: Int,
cdDay :: Int
} deriving ...
data CalendarTime = CalendarTime
{
ctDay :: CalendarDay,
ctTime :: TimeOfDay
} deriving ...
This has an extra level of complexity, but also some advantages:
* It's more internationalisation-friendly, as TimeOfDay can be reused in
other kinds of calendar. In fact, CalendarTime could be parameterised
with a typevar replacing "CalendarDay".
* CalendarDay and possibly TimeOfDay are useful types by themselves, for
instance
dayToCalendar :: JulianDay -> CalendarDay
Other questions:
* Should we include a timezone field in CalendarTime?
* Should the "year" field be an Integer instead of an Int? Assuming
Int=Int32, it gives us 2*10^9 BCE to 2*10^9 CE. The age of the universe
is about 13.7*10^9 years. The age of the earth is about 4.6*10^9 years.
* TimeZone represents a fixed offset to UTC. What should it look like
internally, and what functions on it should we provide?
--
Ashley Yakeley, Seattle WA
