Case-insensitive formats for Data.Time.Format?
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? Also, is there a way to have the parser assume a century of 20 with the format %y? Thanks, Bjorn
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.
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? You can always add 100 to the year after parsing :-) /Björn
On Dec 26, 2007 5:41 PM, Bjorn Bringert
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? Thanks, Bjorn
participants (2)
-
Bjorn Bringert -
Bjorn Buckwalter