This library looks complicated. I think some tutorial documentation about how to implement the following use cases would be very helpful to people that don't really care about leap seconds, etc.

Also, I see references to POXIS and Unix in System.Time.Calendar. What is the portability of this module? Will it be implemented for Windows?

Use cases (primarily taken from real-world corporate IT applications I have developed) :

* What is the equivalent (or closest aproximation) of the SQL DateTime type (date and time without any timezone information)? What is the equivalent of the SQL Date type (date without any timezone information)?

* The user enters a date as "7/4/2005." How do I determine if this date is before or after July 1st of this year?

* How do I present the date "July 1st of this year" to the user in M/D/YYYY format?

* How do I truncate a datetime to midnight of the same day? How do I truncate a date to the first of the month? How do I truncate a date to the first day of the year it occurred in?

* Given a date X, how do I find the last day of the month that X occurs in. For example, If X is July 4th, 2005, then I want the result to be July 31st, 2005. If X is Februrary 5, then I want the result to be Februrary 28 for non-leap-years and February 29 for leap years.

* The user enters a time T with no date, e.g. "17:30". How do I merge this time onto a date D (e.g. July 4, 2005), so that the result has is a datetime with date D and the time T (July 4, 2005 at 17:30).

* Given two datetimes T1, T2, how do I determine if they are on the same date?

- Brian

On 7/5/05, John Meacham <john@repetae.net> wrote:
It needs a
getTAItime :: IO AbsoluteTime
and  a
getLeapSecondTable :: IO LeapSecondTable

Many systems have ways to get at these and it would be a travesty if we
didn't fix this hole in the API when we have the chance. As always, the
library should make its best effort to get at this info. which on POSIX
systems might be converting from UTCtime. but on other systems, TAItime
might be the accurate one and UTCtime will have to be aproximated from
it. (or on systems with up-to-date leap second tables they can both be
accurate).

Also, it would be nice if the LeapSecondTable was not a functional type,
but rather something with structure, like a list of (year,offset) pairs.
There could be apps that will have to look at which years the leap
seconds actually occured in and probing the function with every possible
value in its domain is not very fun.

Also, shouldn't AbsoluteTime be an instance of several Num classes?

What units does DiffTime have? is it relative, or is the length of
a DiffTime independent of what you do to it?

        John
--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries