# 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

```