Malcolm Wallace <malcolm(a)cs.york.ac.uk> wrote,
| The maintainers of nhc98, ghc, and Hugs, are working hard to remove
| any remaining differences in the libraries. So, if you find such
| differences, do please report them to us.
The year value input to Time toClockTime is years since 1900, for
nhc98, but years since 0 for hugs.
As long as the value has to be represented in a 32 bit time_t,
the range of valid years doesn't overlap, so it may be possible
to support both usages. Python does that.
I find another difference in toClockTime, which I think is really
kind of a bug. I haven't looked at the source to see how it happens.
If I supply ctTZ value that is different from the local time zone,
it affects the result. I think this is not really right, but what's
worse, the offset seems backwards. I'm in PDT, -25200 -- that's
what comes out of toCalendarTime, -7 * 3600. If I supply a CDT
offset, -5 * 3600 = -18000, the result time comes out 2 hours
_later_, calculated in PDT. I could be confused about this - the
sun rises in the East, the way I figure it, and when it's 6 AM there,
it's 4 AM here - not 8 AM.
$ runhugs cal.hs 2003
CalendarTime{ctYear=2003,ctMonth=May,ctDay=1,ctHour=5,ctMin=45,ctSec=0,ctPicosec=0,ctWDay=Thursday,ctYDay=0,ctTZName="",ctTZ=-18000,ctIsDST=True}
-> Thu May 1 07:45:00 PDT 2003
-> CalendarTime{ctYear=2003,ctMonth=May,ctDay=1,ctHour=7,ctMin=45,ctSec=0,ctPicosec=0,ctWDay=Thursday,ctYDay=120,ctTZName="PDT",ctTZ=-25200,ctIsDST=True}
Donn Cave, University Computing Services, University of Washington
donn(a)u.washington.edu
-----------------------------
main = do
let calt = CalendarTime {
ctYear = 2003,
ctMonth = May,
ctDay = 1,
ctHour = 5,
ctMin = 45,
ctSec = 0,
ctPicosec = 0,
ctWDay = Thursday,
ctYDay = 0,
ctTZName = "",
ctTZ = -7 * 3600,
ctIsDST = True
}
putStrLn (show calt)
let clt = toClockTime calt
putStrLn ("-> " ++ (show clt))
cal <- toCalendarTime clt
putStrLn ("-> " ++ (show cal))
