time package - parsing of incorrect data

Hi all, I'm experimenting with time package parsing functionalities. I'm trying to verify what happens with inconsistent input data. From what I've seen, incorrect days are "truncated" while incorrect hours are left unmodified leading to inconsistent data. Is this the intended behaviour? Would it be more appropriate to return a parsing Error (Nothing in the following example)? with time-1.1.3:
parseTime defaultTimeLocale "%Y-%m-%d %H:%M" "2008-04-31 25:30" :: Maybe LocalTime Just 2008-04-30 25:30:00
Thanks Paolo

Paolo Losi wrote:
Hi all,
I'm experimenting with time package parsing functionalities. I'm trying to verify what happens with inconsistent input data.
From what I've seen, incorrect days are "truncated" while incorrect hours are left unmodified leading to inconsistent data.
Is this the intended behaviour? Would it be more appropriate to return a parsing Error (Nothing in the following example)?
with time-1.1.3:
parseTime defaultTimeLocale "%Y-%m-%d %H:%M" "2008-04-31 25:30" :: Maybe LocalTime Just 2008-04-30 25:30:00
For instance:
parseTime defaultTimeLocale "%H:%M:%S" "25:74:99" :: Maybe TimeOfDay Just 25:74:99
Currently the parsing code uses construction functions like this: fromGregorian :: Integer -> Int -> Int -> Day TimeOfDay :: Int -> Int -> Pico -> TimeOfDay -- just a constructor Possibly it should use instead "validating constructors" that return a Maybe type. But note that some minutes have 61 seconds, and given that TimeOfDay might be local civil time (UTC + time zone offset), it can be any minute. So these must be allowed: 23:59:60 08:59:60 04:29:60.999999999999 12:17:60.683457690378 Just as UTC requires occasional minutes that have more than 60 seconds, there's a question of whether TimeOfDay might be used with timescales where minutes can have more than 61 seconds. I believe it would be of the order of millions of years before an extended UTC would need more than one leap second every minute. So a validating "fromHourMinuteSecondValid" should check fields like this: 0 <= hour < 24 0 <= minute < 60 0 <= second < 61 -- Ashley Yakeley

Ashley Yakeley wrote:
Possibly it should use instead "validating constructors" that return a Maybe type.
I'm totally in favour of "validating constructors", also for Day values (as an alternative to silent truncation). I guess it would also be useful to differentiate between strict parsing errors (wrong format of the data) and unvalid fields (hour > 24). Ashley, please let me know if you need some "code monkey" help. Thanks Paolo
participants (2)
-
Ashley Yakeley
-
Paolo Losi