Keith Wansbrough writes:

In particular, people often want to compute with time differences: next week, next month, next year, etc. These are calendar operations, and defining precisely what they mean in edge cases is often tricky. Even discounting leap seconds and the like, "next month" is sometimes 28 days into the future, sometimes 29, sometimes 30, and sometimes 31 - and sometimes makes little sense: when is "31 January 2005 plus one month"?

We should look how other languages solve that. C provides only mktime, conversion from a broken-down time which lets out-of-range values adjust larger units. This is not sufficient for implementing adjustment of a single unit in the intuitive way: it can't be done by the naive algorithm of incrementing the value and normalizing the resulting date. For example 30 April + 1 day should be 1 May, but 31 March + 1 month should be 30 April. Yet both calculations would ask to normalize 31 April, and the normalization function doesn't know which out-of-range units have been just set explicitly and should be wrapped, and which result from changing the larger unit and should be clipped. Here is the Java interface: http://java.sun.com/j2se/1.5.0/docs/api/java/util/Calendar.html and the .NET interface: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/... http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/... Both systems allow to adjust individual fields. Java is more complex here, it also provides an interface for rolling with wraparound. Neither language provides a type for representing a timespan which is not a well-defined number of seconds. Java has no timespan type at all, while the .NET TimeSpan can be viewed only in units not larger than a day - no months or years. These languages provide metods for adjustments of individual fields, without materializing the timespan as a whole. * * * .NET provides some calendars other than the Gregorian calendar, while Java does not (but it leaves room for them: there is an abstract class Calendar whose only standard subclass is GregorianCalendar): http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/... * * * Java attacks a problem which .NET doesn't: specifying the date in terms of fields which are usually considered derived from other fields, like day of week and day of year: | If there is any conflict in calendar field values, Calendar gives | priorities to calendar fields that have been set more recently. The | following are the default combinations of the calendar fields. The | most recent combination, as determined by the most recently set | single field, will be used. | | For the date fields: | | YEAR + MONTH + DAY_OF_MONTH | YEAR + MONTH + WEEK_OF_MONTH + DAY_OF_WEEK | YEAR + MONTH + DAY_OF_WEEK_IN_MONTH + DAY_OF_WEEK | YEAR + DAY_OF_YEAR | YEAR + DAY_OF_WEEK + WEEK_OF_YEAR | | For the time of day fields: | | HOUR_OF_DAY | AM_PM + HOUR Since there are various rules about numbering weeks of a year in use, attacking the above problem requires to let the programmer specify the rule. In Java it is done by setting the minimal number of days in the first week of a year, while .NET provides enum CalendarWeekRule with values FirstDay, FirstFullWeek and FirstFourDayWeek, corresponding to the three values actually in use (1, 7 and 4 respectively). * * * For my language Kogut I designed a small interface which I believe is rich enough. A date can be constructed out of fields year, month, day, hour, minute, second, and tick (nanosecond in my implementation). A date also appears to have fields dayOfYear and dayOfWeek, but they are always computed rather than provided on input. There are also timezones; I won't describe them here now. Out-of-range fields are normalized and cause adjustment of other fields on construction. Dates are immutable. The generic operation of functional update of selected fields of a record has a specialized implementation for dates. Since it knows which fields are being set and which are being kept from the date of reference, it can distinguish between changing the day of 30 April to 31 (it gives 1 May) and changing the month of 31 March to April (it gives 30 April). So there are no operations for adding a specific amount to a field, since setting it to the old value + the delta has the right semantics, contrary to mktime. There are no operations for rolling of fields - it's easy enough to perform the modulo by hand. There is no interface for getting or setting the week of a year/month, because they would require additional complexity of selecting the rules to use, and it's easy enough to implement them in terms of the day of the year/month and the day of the week. There is no interface for setting the day of the year, because it's equivalent to setting the corresponding day of January. Time is in 24 hour format - Java provides both formats at once, but I claim that it's easy enough to convert it by hand when needed. There is no type for a timespan, and there will not be. It's easy enough to adjust individual fields. I haven't yet implemented formatting nor parsing of dates. There are too many non-obvious design decisions here. But this will have to be done at some time. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

On Monday 24 January 2005 15:15, Henning Thielemann wrote:

On Mon, 24 Jan 2005, Marcin 'Qrczak' Kowalczyk wrote:

...

We should look how other languages solve that.

A famous solution which evolved on Amiga computers: http://www.datelib.de/index.shtml.en

The advertisement at least sounds like this would be it. I'll take a closer look at it. Ben

Andrew Pimlott wrote:

The best time library I've used is Perl's DateTime. (Anyone who thinks that everything in Perl is a bad hack, please suspend judgement for a minute!) It has DateTime, DateTime::Duration, and DateTime::TimeZone classes (along with a host of supporting players, such as the handy DateTime::Span), and addresses the various ambiguities. (Another example not yet discussed here: The difference between two times can be expressed in years, days, hours, or seconds, so the library lets you choose.) I believe it gets all the date math right, including leap seconds. It is the result of considerable development, use, and experience with other time libraries.

The project is at

http://datetime.perl.org/

and if you click the modules link, you can read the documentation.

There certainly seem to be a lot of good ideas here. In addition to DateTime and DateTime::Span there are sets DateTime::Set and DateTime::SpanSet for representing various kinds of sets of time. Various events and calendars make use of these. -- Ashley Yakeley, Seattle WA

Just a thought: I think we all agree on having Time as an Integer or similar representing time with some particular resolution. The question seems to be how to deal with CalendarTime, defined as a record with fields for the various components found in a human-type time stamp. I wonder if it would be worthwhile to pursue a slightly different approach? The rationale goes as such: we use a calendar and clock not necessarily to mark points in time, but to be able to point to some particular day, month, hour, etc. Would it be an idea to define something like (very rough draft here): data T = Y Int | M Int T | Wy Int T | Wm Int T | Dy Int T | Dm Int T | Dw Int T | Hr Int T | Min Int T deriving (Eq,Show) The idea is that time can be a year, or a month in some year, or a week in some year (yes, I know it's ambigous), week in month (in year), day in year, day in month in year, and so on. Clearly, deriving Eq is not a good idea - I think Eq should consider a Dy and Dm equal if they refer to the same day. Now, some functions to construct values of Time could be year y = Y y month m (Y y) = M m (Y y) And why not create multiple values in one go: months (Y y) = [M m (Y y) | m <- [1..12]] days (Y y) = [Dy d (Y y) | d <- [1..(if y `mod` 4 == 0 then 366 else 365)]] days (M m yy@(Y y)) | m `elem` [1,3,5,7,8,10,12] = [Dm d (M m yy) | d <- [1..31]] | m == 2 = [Dm d (M m yy) | d <- [1..if y `mod` 4 == 0 then 29 else 28]] | otherwise = [Dm d (M m yy) | d <- [1..30]] Now it's easy to get all the days of December this year: *Main> days $ last $ months $ year 2005 [Dm 1 (M 12 (Y 2005)),Dm 2 (M 12 (Y 2005)),Dm 3 (M 12 (Y 2005)),Dm 4 (M 12 (Y 2005)),Dm 5 (M 12 (Y 2005)),Dm 6 (M 12 (Y 2005)),Dm 7 (M 12 (Y 2005)),Dm 8 (M 12 (Y 2005)) [...] So, if my local Linux user group has meetings the last Thursday each month, this can be written something like map (last . filter isThursday . days) (months $ year 2005) It's just an idea, but perhaps worth considering? Comments welcome! -kzm -- If I haven't seen further, it is by standing in the footprints of giants

Graham Klyne writes:

At 08:56 25/01/05 +0100, Ketil Malde wrote:

...

I think we all agree on having Time as an Integer or similar representing time with some particular resolution. The question seems to be how to deal with CalendarTime, defined as a record with fields for the various components found in a human-type time stamp.

Just for the record, my silence is not consent on this. [..] (days,ticks)

This (almost) falls in under "similar". Unless you feel this model subsumes the "calendar" type of time, in which case I'd like to see the reference as well. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

Graham Klyne wrote:...

I regard timezones (as opposed to timezone offsets from UTC) and leap seconds as specialized issues that don't impact many of the common uses for date/time. A time library shouldn't preclude sensible implementations of these, but I don't think it needs to include them all.

It will need proper timezone information. For example if it does not include the proper information for UK daylight savings time, my Personal-Video-Recorder box, written in Haskell, will record the wrong programs in summer. Keean.

Ketil Malde wrote:

Would it be an idea to define something like (very rough draft here):

data T = Y Int | M Int T | Wy Int T | Wm Int T | Dy Int T | Dm Int T | Dw Int T | Hr Int T | Min Int T deriving (Eq,Show)

The idea is that time can be a year, or a month in some year, or a week in some year (yes, I know it's ambigous), week in month (in year), day in year, day in month in year, and so on.

This seems to be equivalent to DateTime::Incomplete in Perl's DateTime. If so I'd consider representing it more like this: data T = MkT y :: Maybe Int m :: Maybe Int wy :: Maybe Int wm :: Maybe Int ... -- Ashley Yakeley, Seattle WA