On Mon, Jun 16, 2003 at 04:42:53PM +0100, Graham Klyne wrote:
... I think it's quite usual for people and applications to deal with a day as a consistent time interval without concern for possible leap seconds, so dealing with days as intervals of 24*60*60 seconds is useful for a majority of applications that deal with such intervals.
What about the fact that days are not actually intervals of 24*60*60 seconds (as I'm sure you know)? Most applications don't care, but it's crucial to give correct and unsurprising results.
I'm worried that the complexity to deal with leap seconds will end up being just as complicated as the complexity to deal with more general TimeDiff's as in the current library, in which case it may be necessary to bite the bullet and specify the behaviour of TimeDiffs completely and accurately.
Agreed, this discussion tends to get rather vague at times, so I'd like to put it on a more concrete footing if I may. I've put together rough suggestion for a starting point for a replacement System.Time, appended below. Please comment! Cheers, Simon ------------------------------------------------------------------------ ---- -- * ClockTime -- | A representation of absolute time data ClockTime = ClockTime { ctSeconds :: Integer, ctPicoseconds :: Integer } deriving (Eq, Ord, Show, Read) -- | returns the current absolute time getClockTime :: IO ClockTime -- | Difference between two 'ClockTime's data TimeDiff = TimeDiff { tdSeconds :: Integer, tdPicoseconds :: Integer } deriving (Eq, Ord, Show, Read) -- | An empty 'TimeDiff' noTimeDiff :: TimeDiff -- | Returns the difference between two 'ClockTime's diffClockTimes :: ClockTime -> ClockTime -> TimeDiff -- | Adds a 'TimeDiff' to a 'ClockTime' addToClockTime :: ClockTime -> TimeDiff -> ClockTime {- Rationale: - TimeDiff is now an absolute measure of time period. Invariants: t1 `addToClockTime` (t2 `diffClockTimes` t1) == t2 t1 `addToClockTime` noTimeDiff == t1 t1 `diffClockTimes` t1 == noTimeDiff TODO: - This representation of TimeDiff is maybe not the best. Two other possibilities: use just picoseconds, or have the type be abstract with a way to extract picoseconds. - If we keep the seconds/picoseconds representation, should we specify that the TimeDiff returned by diffClockTimes is normalised? Should we provide a way to normalise a TimeDiff? -} ------------------------------------------------------------------------ ---- -- * CalendarTime data CalendarTime = CalendarTime { ctYear :: Int, ctMonth :: Month, ctDay :: Int, ctHour :: Int, ctMin :: Int, ctSec :: Int, ctPicosec :: Integer, ctTZ :: Timezone } deriving (Eq, Ord, Read, Show) data Timezone -- abstract -- | Make a 'Timezone' -- TODO: do we need to specify daylight savings time too? timezoneFromOffset :: Int -> Timezone timezoneFromName :: String -> Timezone timezoneOffset :: Timezone -> Int timezoneName :: Timezone -> String -- | Convert a 'ClockTime' to a 'CalendarTime' in the current timezone clockTimeToCalendarTime :: ClockTime -> IO CalendarTime -- | Convert a 'ClockTime' to a 'CalendarTime' in UTC clockTimeToUTCTime :: ClockTime -> CalendarTime -- | Convert a 'CalendarTime' to a 'ClockTime' -- TODO: can this raise an exception if the CalendarTime does not -- represent a valid time? Or should it return Maybe ClockTime? calendarTimeToClockTime :: CalendarTime -> ClockTime -- OPTIONAL: these are hard to implement, and require -- careful specification (see rationale below): addPicoseconds :: CalendarTime -> Integer -> CalendarTime addSeconds :: CalendarTime -> Integer -> CalendarTime addMinutes :: CalendarTime -> Integer -> CalendarTime addDays :: CalendarTime -> Integer -> CalendarTime addWeeks :: CalendarTime -> Integer -> CalendarTime addMonths :: CalendarTime -> Integer -> CalendarTime addYears :: CalendarTime -> Integer -> CalendarTime {- Rationale: - Adding "irregular" time differences should be done on CalendarTimes, because these operations depend on the timezone. - Need to define the meaning when the offset doesn't exist. eg. adding a day at the end of the month clearly rolls over into the next month. But what about adding a month to January 31st? -}