Case-insensitive formats for Data.Time.Format?

Bjorn Buckwalter bjorn.buckwalter at
Wed Dec 26 20:38:19 EST 2007

On Dec 26, 2007 5:41 PM, Bjorn Bringert <bringert at> wrote:
> On Dec 26, 2007, at 20:15 , Bjorn Buckwalter wrote:
> > Hello all,
> >
> > Is there a compelling reason to not make the formats in
> > Data.Time.Format
> > case-insensitive when parsing? This would apply to the months,
> > weekdays, time
> > zone. (I see there are already two formats %p and %P corresponding
> > (confusingly)
> > to AM/PM and am/pm respectively.)
> >
> > What got me thinking about this is that I'm being supplied with
> > dates on the
> > format "26 DEC" which will not parse without munging. I suspect
> > such situations
> > are fairly common?
> I agree. The parser should be more liberal. I originally implemented
> rather faithful inverses of the formatting directives, but I don't
> really see any point in being very strict when parsing.
> You are welcome to submit a patch for this, or at least a feature
> request in Trac to keep it from being forgotten.

I submitted ticket #2003 to the GHC Trac which I realize may not be
what you were referring to. Is there a more general Trac for libraries
which are presumably not GHC-specific? (Excuse my ignorance.)

> > Also, is there a way to have the parser assume a century of 20 with
> > the
> > format %y?
> No. Do you have any ideas for how this could be implemented?

Perhaps a parsing function with a "template" epoch for filling in the
missing fields, e.g.:

  readTimeWithTemplate :: ParseTime t => t -> TimeLocale -> String ->
String -> t

In fact, it seems that the current 'readTime' would be a variation of:

  readTime = readTimeWithTemplate (UTCTime (FromGregorian 1970 1 1) 0)

I'd argue that this particular "template" epoch is unlikely to be
useful except for the special case of programming language interop.
But since that is how things currently work (in Haskell and most other
programming languages it would seem) perhaps a variation with a
user-defined template is a reasonably natural extension?


More information about the Libraries mailing list