[GHC] #9150: libraries/time: parseTime barfs on leading space in format string

[GHC]

#9150: libraries/time: parseTime barfs on leading space in format string
-------------------------------------+-------------------------------------
              Reporter:  mjo         |             Owner:  Ashley Yakeley
                  Type:  bug         |            Status:  new
              Priority:  normal      |         Milestone:
             Component:  libraries   |           Version:  7.8.2
  (other)                            |          Keywords:
            Resolution:              |  Operating System:  Unknown/Multiple
Differential Revisions:              |   Type of failure:  Incorrect result
          Architecture:              |  at runtime
  Unknown/Multiple                   |         Test Case:
            Difficulty:  Unknown     |          Blocking:
            Blocked By:              |
       Related Tickets:              |
-------------------------------------+-------------------------------------
Changes (by Ashley Yakeley):

 * owner:   => Ashley Yakeley


Comment:

 This is awkward. The problem is that `parseTime` discards leading and
 trailing spaces in the input string when formatting. The obvious solution
 is to discard leading spaces in the format string. But here's a more
 difficult case:

 {{{
 parseTime defaultTimeLocale "%Q " " " :: Maybe LocalTime
 }}}

 `%Q` matches the empty string, so one would expect this to match. However,
 `parseTime` discards leading spaces, `%Q` matches the empty string, and
 the following space can't be matched.

 Alternatively, instead of skipping initial spaces with `skipSpaces`, one
 can parse them with `skipMany (satisfy isSpace)`. But now this gives
 `Nothing`:

 {{{
 parseTime defaultTimeLocale "%k" " 8" :: Maybe LocalTime
 }}}

 This ends up parsing two ways: the first when initial skipping grabs the
 space, and the second when `%k` grabs the space. They end up with the same
 value, but currently we need exactly one parse for `parseTime` to give a
 `Just` value.

 Another alternative would be to drop skipping of leading and trailing
 spaces. This would make the behaviour of the parsing functions more
 predictable. However, the current behaviour has been there since time-1.1
 from 2007, so programs that depend on it will fail with stricter
 functions.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9150#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler