Proposal: Add parsing (and some other changes) to the time package

[Clifford Beshers]

I just started to use the time library and had to work around several 
issues, one of them was the %S issue including the fractional 
component.  Also, the %_d in the RFC822 format string is not honored and 
the result is formatted incorrectly.

I also didn't find a test suite and I think it could use one.

So I endorse the fixes and enhancements and would be happy to discuss 
helping out with some of the enhancement implementations.

Cliff


Bjorn Bringert wrote:
> There haven't been any responses to this proposal for over a week now, 
> which I interpret as consent and/or indifference. I will push the 
> implemented features and fixed bugs to 
> http://darcs.haskell.org/packages/time/ and then start implementing 
> the rest (when I find the time).
>
> /Björn
>
> On 16 nov 2006, at 14.56, Bjorn Bringert wrote:
>
>> I propose adding parsing to the time package. I also propose some minor
>> other changes and bugfixes. I have implemented the changes that I 
>> consider
>> reasonably clear-cut. The rest I will implement after community input.
>>
>> All already implemented changes are available from:
>> http://www.cs.chalmers.se/~bringert/darcs/time/
>>
>> All objections, comments, etc. are welcome. I especially would like 
>> feedback on the
>> unimplemented enhancements, and any objections to the already 
>> implemented ones.
>>
>> I have created ticket #1007 to track this proposal: 
>> http://hackage.haskell.org/trac/ghc/ticket/1007
>>
>> Proposal:
>>
>> == Executive summary ==
>> (see below for more details).
>>
>> === Implemented enhancements ===
>>
>> * Add time parsing to the time package, including Read instances.
>>
>> * Add fromMondayStartWeek and fromSundayStartWeek.
>>
>> * Add secondsToDiffTime and picosecondsToDiffTime.
>>
>> === Unimplemented enhancements ===
>>
>> * Change %S to: the number of whole seconds.
>>
>> * Add %q: the number of picoseconds (including trailing zeroes).
>>
>> * Add %Q: decimal point and second decimals, without trailing zeros.
>>
>> * Add %f: The century part of the week date year.
>>
>> * Change %Z to produce the time zone offset if the time zone name is "".
>>
>> * Add Eq and Ord instances for ZonedTime?
>>
>> * Add Typeable and Data instances for all the time package types.
>>
>> === Fixed bugs ===
>>
>> * formatTime "%c" did not include the time zone when applied to 
>> ZonedTime or UTCTime.
>>
>> * s/propleptic/proleptic/ in some Haddock comments.
>>
>> * formatTime documentation of range of %U and %W was wrong, should 
>> include 00.
>>
>> * The showWeekDate Haddock comment was missing the example.
>>
>> * The taiEpoch Haddock comment was missing the epoch time.
>>
>> === Unfixed bugs ===
>>
>> * Haddock comments for toJulianYearAndDay and isJulianLeapYear talk 
>> about the Gregorian calendar.
>>
>>
>> == Details ==
>>
>> === Implemented enhancements ===
>>
>> * Add time parsing to the time package.
>>
>> Rationale:
>> The old System.Time has had a TODO  "* add functions to parse strings to
>> `CalendarTime' (some day...)" for a long time. The question about 
>> date parsing
>> comes up once in a while on the mailing lists
>> (e.g. http://comments.gmane.org/gmane.comp.lang.haskell.cafe/16438).
>>
>> * Add fromMondayStartWeek and fromSundayStartWeek to 
>> Data.Time.Calendar.OrdinalDate.
>>
>> Rationale:
>> I can't find any duals of mondayStartWeek and sundayStartWeek. They
>> are useful when implementing parsing for %W and %U.
>>
>> * Add secondsToDiffTime and picosecondsToDiffTime.
>>
>> Rationale:
>> As has come up on haskell-cafe
>> (http://comments.gmane.org/gmane.comp.lang.haskell.cafe/15653), it
>> takes a while to figure out how to make DiffTime values.
>>
>> secondsToDiffTime is not that important since it is just another name
>> for fromInteger, but I suspect that it would be used a lot.  Using
>> fromRational to create a DiffTime from a number of picoseconds is a
>> bit of a hassle, so having a picosecondsToDiffTime would be useful.
>>
>>
>>
>> === Unimplemented enhancements ===
>>
>> * formatTime: Change %S to: the number of whole seconds.
>> * formatTime: Add %q: the number of picoseconds (including trailing 
>> zeroes).
>> * formatTime: Add %Q: decimal point and second decimals, without 
>> trailing zeros.
>> If the number of picoseconds is zero, nothing is produced (not even 
>> the decimal point).
>>
>> Rationale:
>> Currently %S includes decimals if there are any. This is different
>> from strftime, and there is no format specifier for just the integer
>> part of the seconds. It would be nice to have such a specifier to
>> implement many standard date formats (e.g. RFC 822). Also a specifier
>> for second decimals would also help when using %s. Currently there is
>> no reasonable way to get more than integer second precision with
>> since-epoch timestamps.  Thus the current %S would be equivalent to
>> %S%Q under this proposal.
>>
>>
>> * Add %f: The century part of the week date year.
>>
>> Rationale:
>> There is a %g specifier for the last two digits of the week date 
>> year, but no specifier
>> for the century. %C cannot be used, since the normal century and the 
>> week date
>> century can differ:
>> {{{
>> > formatTime defaultTimeLocale "%Y %G" (fromGregorian 2000 1 1)
>> "2000 1999"
>> }}}
>>
>> * Change %Z to produce the time zone offset if the time zone name is "".
>>
>> Rationale:
>> Without this, if you format a ZonedTime which contains an unnamed 
>> timezone,
>> %Z produces the empty string. This is invalid in many formats. It 
>> would be better
>> to output the offset when there is no timezone name.
>>
>>
>> * Add Eq and Ord instances for ZonedTime?
>>
>> Rationale:
>> It's useful at least for the QuickCheck properties, but probably also
>> elsewhere. There are lots of standard functions that want Eq and Ord.
>>
>> Problems:
>>
>> Should ZonedTimes be converted to UTC and compared, or should times in
>> different timezones never be equal? I would argue for the latter, but
>> I suspect that this problem is the reason why it never got included in
>> the first place.
>>
>> Interestingly, there is a derived instance of Eq for TimeZone, which
>> means that timezones with the same offset but different names are
>> considered different. Following this logic, I think that ZonedTimes
>> with different timezones should also be different. This should be
>> noted in the documentation.
>>
>> * Add Typeable and Data instances for all the time package types.
>>
>> Rationale:
>> It's useful and doesn't hurt anyone.
>>
>>
>> === Fixed bugs ===
>>
>> * formatTime "%c" does not include the time zone even when applied to 
>> ZonedTime
>> or UTCTime, since "%c" is handled by the FormatTime LocalTime instance:
>>
>> {{{
>> > fmap (formatTime System.Locale.defaultTimeLocale "%c") getZonedTime
>> "Sat Nov 11 19:12:45.395568  2006"
>> > fmap (formatTime System.Locale.defaultTimeLocale "%c") getCurrentTime
>> "Sat Nov 11 18:13:52.010944  2006"
>> }}}
>>
>> * s/propleptic/proleptic/ in Data/Time/Calendar/JulianYearDay.hs and 
>> Data/Time/Calendar/OrdinalDate.hs
>>
>> * formatTime documentation of range of %U and %W was wrong, should 
>> include 00.
>>
>> * The showWeekDate haddock comment is:  "show in ISO 8601 Week Date 
>> format as yyyy-Www-dd (e.g."
>>
>> * The taiEpoch haddock comment is just "The epoch of TAI, which is"
>>
>>
>> === Unfixed bugs ===
>>
>> * The haddock comments for toJulianYearAndDay and isJulianLeapYear in
>> Data.Time.Calendar.JulianYearDay talk about the proleptic Gregorian 
>> calendar.
>> This looks like a copy-and-paste problem. What is the calendar 
>> called? Proleptic Julian?
>>
>>
>> /Björn Bringert
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries