Computer Languages, Systems & Structures 32 (2006) 157–183 www.elsevier.com/locate/cl A point based model of the Gregorian Calendar Hernán Wilkinsona,∗,1, Máximo Prietob, Luciano Romeoa,2 aTacuarí 202, 7mo Piso, C1071AAF, Buenos Aires, Argentina bLifia - Facultad de Informática, Universidad Nacional de La Plata, cc11, 1900, La Plata, Argentina Received 3 October 2005 Abstract Time is an important aspect of all real world entities; temporal information is crucial in many computer-based applications. The Smalltalk community does not have a good model of the time domain. Smalltalk-80 and its commercial implementations provide only the classes Date and Time to model time domain entities. Squeak augmented the model with the abstractions Timespan, Year, Month and Week. These models fall short when complex situations of the time domain have to be programmed, forcing the programmers to create their own and repetitive solutions. In this paper, we present a model of the Gregorian Calendar based on a metaphor that maps time entities into points of lines, each line with its own resolution. The model addresses a great amount of functionality and reifies almost all the Gregorian Calendar entities. It allows programmers to design and program time related issues better than current time domain implementations, and in a more natural way. © 2005 Elsevier Ltd. All rights reserved. Keywords: Smalltalk; Date; Time; Gregorian calendar; Time span; Time intervals; Time line filter; Relative dates; Test driven development 1. Introduction Time entities are an important aspect of many computer applications. For example, the financial domain has a strong coupling with the time domain because the value of any financial instrument is related to a certain point in time (i.e., the value of one Euro today is not the same as it was two years ago), financial operations among traders could be settled some time after a given date (i.e., 48 h after today), instrument cash flows depend on dates relative to a certain calendar, and so on. Office information systems depend on time information to pay salaries, allow employees to leave on vacation, etc. Real time systems base their behaviour on timed events, verify the temporal evolution of the environment they control, etc. Different types of temporal entities exist, such as • Specific points in the time line, such as 01/01/2005 (defined as anchored data by [1]). • Measures of time, such as 1 day (defined as unanchored temporal information by [1]). • Temporal information about occurred events, such us “John played his guitar while Paul was outside” [2]. ∗ Corresponding author. Tel.: +54 11 4878 1116x120. E-mail addresses: [email protected] (H. Wilkinson), maximo.prieto@lifia.info.unlp.edu.ar (M. Prieto), [email protected] (L. Romeo). 1 Mercap Development Manager. 2 Mercap Software Architect. 1477-8424/$ - see front matter © 2005 Elsevier Ltd. All rights reserved. doi:10.1016/j.cl.2005.10.001 158 H. Wilkinson et al. / Computer Languages, Systems & Structures 32 (2006) 157–183 Many time models have been proposed in the past [1,3–6] but none of those models are provided within the Smalltalk environments. Most of them are related to other technologies such as relational databases or artificial intelligence systems. Works such as [7] and [8] propose changes to the ODMG [9] object model adding temporal tracking to objects, but they do not augment the ODMG time model which lacks important time abstractions. Other programming languages such as Java [10] and .NET [11] provide basic time models that suffer from important design flaws as we show in Section 6.3, Comparison with other Research Work. Barbic et al. in [12,13] classifies temporal systems in two categories, those that model Time Representation and those that model Time Reasoning. The former deals with the “representation” of time entities (time points vs. time intervals), time ordering (linear, circular or branching), time boundedness (i.e., modelling of finite or infinite times) and time measures (distance between time entities, arithmetic on those measures). The latter focuses on the specifications of a time calculus to manage temporal information and a query language to extract temporal information about time events. We present in this paper an object model that focuses on the Gregorian Calendar Time Representation, imple- mented with Smalltalk, which provides abstractions for many of the time domain entities that are not model in current implementations and faces many design challenges such as • Gregorian Calendar irregularity (Months have 28, 29, 30 or 31 days; there are leap and non-leap years) • Time entities comparison consistency. We want to express comparisons as ◦ January < July ◦ January first < February twentyNinth ◦ 3 months < 1year or 5 days < 1 week • Time entity distance awareness, no matter the type of the entity ◦ (January distanceTo: July) = (January, 2005 distanceTo: July, 2005) • Relative dates according to a filter applied to the time line ◦ 14 days from: (April first, 2005) counting: workingDays The model is based on a metaphor that proposes to see time entities as points of the time line with four different resolution and it uses Measures [17] to represent the distance between two points in the time line, not just numbers as is commonly done in other models. The scope of the model is limited to the Gregorian Calendar decreed by Pope Gregory XIII [19]. No support is given neither for the Hindu Calendar nor for the Iranian one or any other calendar. See [19] for a complete description of these calendars. The remaining of this paper is organised as follows: Section 2 expands the problem we present in this paper. Section 3 presents the metaphor we based the model on. Section 4 discusses the model’s design and behaviour. Section 5 presents the implementation. Section 6 compares the model with other time related models. Finally, Section 7 concludes the paper and gives directions for future research. 2. The problem Smalltalk-80 [14] provides a basic time model implementation of the Gregorian Calendar. That model does not provide good solutions to all possible time related problems mainly because: • It lacks proper abstractions of some important time domain entities (i.e., month, day) • Time objects are not immutable (i.e., Time) therefore, they do not properly model time entities as we show in Section 4.1, Time Entities Immutability and Validity. Smalltalk-80 provides only two classes to model time entities: Date and Time. Instances of Number and Symbol are used to represent time entities such as days, months, months of years, etc. For instance, the message #year implemented in Date returns a Number not an object that reifies an entity “year”. The same is also true with the message #day,it returns a Number representing the day number not a “day”. To obtain the month of a Date it is even harder because the model does not have a month class. Date provides two messages to accomplish that requirement, #monthName and #monthIndex. The former returns a Symbol (i.e., #February) and the latter a Number representing the position of that month in a Gregorian year (i.e., 2 for February). H. Wilkinson et al. / Computer Languages, Systems & Structures 32 (2006) 157–183 159 The lack of abstractions makes the model difficult to use when complex time related calculations and situations need to be programmed. For instance, the Smalltalk-80 model does not easily solve the problem of getting the number of days of a month because the object that represents a month is a Symbol or a Number and neither of them answers the message #numberOfDays. Class protocol is provided in Date to answer that question with the message #daysInMonth: aMonthName forYear: anInteger but we argue that the class Date should not be responsible for this behaviour. A better solution would reify the “month of year” concept providing to this abstraction the necessary behaviour. Comparing days of week is another problem generated by the lack of abstractions. Because days of week are modelled as instances of Symbol, the alphabetic order is used when they are compared. Code Sample 1 shows these examples. “Note that the message #daysInMonth:forYear: is sent to the class Date” today := Date today. Date daysInMonth: today monthName forYear: today year. “It returns false” #Monday < #Friday Code Sample 1. Getting the number of days of a year’s month. The Chronology package [15] released with Squeak 3.7 [16] provides abstractions proposed by the ANSI Standard [20] like the class DateAndTime and the class Duration. It also reifies concepts like Year, Month and Week, implemented as subclasses of Timespan, but: • It lacks a good separation between anchored and unanchored time entities. • It represents time entities as segments of the time line, not as points. • It does not model important time entities such as month (i.e., January) and day (i.e., Monday). Squeak’s lack of abstractions, although less that Smalltalk-80, produces the same problems. The meaning of some abstractions can, at first, produce misinterpretations such as the class Month, which does not represent a month (i.e., January) but a month in a year (i.e., January 2005). But the main problem we found with this model is that time entities are modelled as segments in the time line; all the time classes are subclasses of Timespan. This modelling decision merges two different concepts, time points and time segments in one, which allows comparing entities of different granularity such as years and dates (i.e., year 2005 and January 2nd of 2005). Representing time entities as time segments does not allow to create a total order among them, as it is explained in Goralwalla et al. in [1]. Therefore, the result of comparing time entities could be “unknown” (i.e., year 2005 is not less, equal or greater than January 2nd of 2005) and the “unknown” entity is not modelled in Squeak.