#3859: Problems with toClockTime on NetBSD
---------------------------------+------------------------------------------
Reporter: igloo | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.12.2
Component: Compiler | Version: 6.12.1
Keywords: | Difficulty:
Os: NetBSD | Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
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='[email protected]' 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='[email protected]' 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).
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3859>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
