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