Calendar Types

Ashley Yakeley ashley at semantic.org
Sat Feb 12 22:23:39 EST 2005


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



More information about the Libraries mailing list