Proposal: Add parsing (and some other changes) to the time package
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
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@haskell.org http://www.haskell.org/mailman/listinfo/libraries
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@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
participants (2)
-
Bjorn Bringert -
Clifford Beshers