Opened 7 years ago

Closed 4 years ago

#1007 closed proposal (fixed)

Add parsing (and some more) to the time package

Reported by: bringert@… Owned by:
Priority: normal Milestone: Not GHC
Component: libraries (other) Version:
Keywords: Cc: alistair@…, pho@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

I propose adding parsing to the time package. I also propose some minor
other changes and bugfixes. I have implemented the changes that I considered
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.

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 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.

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

> 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"
  • 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?

Change History (8)

comment:1 Changed 7 years ago by arthurvl@…

Me like.

In more detail: yes, Eq and Ord instances for ZonedTime? would be very useful in calendaring applications, together with ranged sets. Furthermore, the parsing really really really is helpful.

The printing 'enhancements' seem well argued, and imo should just go in.

I'm not so sure about the secondsToDiffTime and picosecondsToDiffTime though. I like the idea of denoting difftimes with integral denotations. The use of fromInteger might be documented better...

comment:2 Changed 7 years ago by igloo

  • Milestone set to Not GHC

comment:3 Changed 7 years ago by bringert

Almost all of the proposed changes are now implemented. These are still unimplemented:

  • Add Eq and Ord instances for ZonedTime?.
  • Add Typeable and Data instances for all the time package types.
  • toJulianYearAndDay and isJulianLeapYear

comment:4 Changed 6 years ago by abayley

  • Cc alistair@… added

See also ticket 1598, for Data and Typeable instances.

comment:5 Changed 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:6 Changed 6 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:7 Changed 4 years ago by PHO

  • Cc pho@… added
  • Type of failure set to None/Unknown

comment:8 Changed 4 years ago by igloo

  • Resolution set to fixed
  • Status changed from new to closed

Apparently mostly done, and the rest looks like an abandoned proposal.

Note: See TracTickets for help on using tickets.