id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,os,architecture,failure,difficulty,testcase,blockedby,blocking,related
3859,Problems with toClockTime on NetBSD,igloo,,"http://bugs.darcs.net/msg8960 (part of http://bugs.darcs.net/issue1524) says:
{{{
Got it: reproducing the crash (tough on such a slow machine where rebuilding 
these things is quite the process, yay me):

<patch author='zooko@zooko.com' date='20090308025039' local_date='Making 
friendly CalendarTime {ctYear = 2009, ctMonth = March, ctDay = 8, ctHour = 2, 
ctMin = 50, ctSec = 39, ctPicosec = 0, ctWDay = Sunday, ctYDay = 0, ctTZName = 
""GMT"", ctTZ = 0, ctIsDST = False}

Plugging that into your first requested program:

import System.Time

-- this is one line
main = print . toClockTime $ CalendarTime 2009 March 8 2 50 39 0 Sunday 0 ""GMT"" 
0 False

... returns:

t: user error (Time.toClockTime: invalid input)

So..  This suggests to me there are two problems. First, the toClockTime 
function has trouble with certain input.

This fails:
-- this is one line
main = print . toClockTime $ CalendarTime 2009 March 8 2 59 59 1000 Thursday 
280 ""BST"" 3600 True

This succeeds:
-- this is one line
main = print . toClockTime $ CalendarTime 2009 March 8 3 0 0 0 Thursday 280 
""BST"" 3600 True

Weird huh?

And then clearly, the second problem appears to be the conversion of the 
datestamp in the following partial log entry:

<patch author='zooko@zooko.com' date='20090308025039' local_date='Making 
friendly CalendarTime {ctYear = 2009, ctMonth = March, ctDay = 8, ctHour = 2, 
ctMin = 50, ctSec = 39, ctPicosec = 0, ctWDay = Sunday, ctYDay = 0, ctTZName = 
""GMT"", ctTZ = 0, ctIsDST = False}

(This is with a modified darcs with the printf-equivalent in it.)

This is suspiciously near to the DST switchover. If you need a zdump of my 
current DST timings, I can provide the pre-zic entries.

Is there perhaps a DST switchover assumption in that logic?

Let me know if you'd like me to delve further. Hopefully this is enough to make 
the problem clear to you darcs folks.
}}}

This really needs to be looked at by someone with access to NetBSD (or perhaps some similar OS).
",bug,new,lowest,7.6.2,Compiler,6.12.1,,,zooko@…,NetBSD,Unknown/Multiple,None/Unknown,,,,,