Language Madness Naming Time Elements

Introduction

Programmers still have serious difficulties coding with time values, and to prove this, it suffices to examine the most popular forums on the Internet "For those who code" as CodeProject, StackOverflow and others. And the requirements to include time values in information processing are increasing every day.

In the Java community, significant progress has been made, materialized in Joda Time and JSR 310, while in the .NET community, a significant evolution materialized in the .NET Framework is not observed. Here, things are very quiet, as if everything were fine as it is. Although in .NET we have also Noda Time, which emulates Java’s Joda Time, it seems as if the .NET Framework team is not interested in creating their JSR 310.

But I have noticed a common trait in these developments: The complexity increases, to cover a wider range of use cases, but on the same deficient conceptual basis, perhaps to avoid a break in compatibility, which already seems inevitable.

I've always wondered why processing time values HAS to be so complex, if it is a necessary and inevitable or artificial and reducible complexity. Time is simple but the way we measure, represent and express it is very complex, mainly because it depends on ancient methods that can’t be changed and cultural differences that should (have to) be respected. So, time is simple but programming time is cumbersome.

Maybe a greater effort of abstraction has been missing to separate the essentials from the decorative, to process them separately and thus reduce complexity, but also evident is a notorious lack of care in the nomenclature, in the way of naming things.

Although my interest focuses on .NET, the conceptual foundations about time precede any attempt of implementation, as a programming language or class library, and should be common to all. However, each software product has independent and isolated development teams which may agree on concepts but not always on how to name them.

Even worse, the teams that develop standards also name things their way, without seeking widespread consensus, and so instead of having a standard to follow, we have several, which agree in essence but differ in nomenclature. And sometimes in different names, subtle conceptual differences are hidden, which in the case of time values has led us to the situation described in the article title.

It may seem that this is not the right point to start rethinking, from scratch, a better approach for processing time values, but the caveat is that when we express concepts, we have to use appropriate nomenclature to avoid repeating the current chaos.

Background

To illustrate the point, I chose an old unresolved discrepancy: ‘Interval’ Vs ‘Period’. What in ISO 8601 is named as Interval, in the field of databases (SQL standard) is called Period, and what in the first is called Duration, in the second is called Interval, and as if this weren’t enough, in Joda, Noda and JSR 310, a SQL programmer will find two types of his/her Interval: one called Duration and another one called Period. The following table summarizes the confusion:

	Specific timeline segment	Amount of time (Duration)
	e.g.   2015-10-29   to   2015-10-31T10:30:00	e.g.   3 days   Or   3 days + 10 hours + 30 minutes
ISO 8601	Time Interval: A time interval is the intervening time between two time points (start and end). The amount of intervening time is expressed by a duration.	Duration: Durations are a component of time intervals and define the amount of intervening time in a time interval.
SQL 2011	Period: A period definition for a given table associates a period name with a pair of column names defined for that table. The columns shall both be of a datetime data type and not nullable.	Interval: A value of an interval type represents the duration of a period of time. There are two classes of intervals: year-month intervals and day-time intervals.
.NET Frame work	Not Available.	TimeSpan: Represents a time interval (duration or elapsed time). Can be expressed as a positive or negative number of days, hours, minutes, seconds, and milliseconds. It cannot be expressed in terms of years and months. The value of a TimeSpan object is a number of ticks (100 nanoseconds).
NODA Time (Derived from JODA Time)	Interval: An interval between two instants in time (start and end). The interval includes the start instant and excludes the end instant, unless the end instant is MaxValue in which case it's deemed to be inclusive. The end may equal the start (resulting in an empty interval), but will not be before the start.	Duration: Represents a fixed (and calendar-independent) length of time. A duration is a length of time defined by an integral number of 'ticks', where a tick is equal to 100 ns. Although durations are usually used with a positive number of ticks, negative durations are valid. Period: (A complex duration) Represents a period of time expressed in human chronological terms: hours, days, weeks, months and so on. Periods can contain negative units as well as positive units.
Oracle Database (12c)	Not available as data type. (Available for Temporal Validity Support).	INTERVAL YEAR TO MONTH: Stores a period of time in years and months. INTERVAL DAY TO SECOND: Stores a period of time in days, hours, minutes, and seconds.
You and Me (Sometimes, Some places, Depends …)	Sometimes Interval, sometimes Period.	Sometimes Interval, sometimes Period, sometimes TimeSpan, sometimes Duration.

Footnotes:

1. The same thing has different names in different contexts.
2. One thing “here” is named equally as the other thing “there”.
3. The same programmer, in the development of the same application, in different layers (business, database, UI), has to use the same name for different things and different names for the same thing.
4. The definition text of many words (names) contains the defined word or, even worse, an antagonist word of which it should be differentiated.

Epilogue: If we use the word “Time” to mean “Time-of-day”, which word should we use to mean “Time” by itself? E.g.: A namespace or class named “Time” would be understood as “Time-of-day”? … How should such namespace or class be named, so that it is understood as the universal concept of “Time”?

In short, they have "burned" several good names: Interval, Period, Duration and TimeSpan, which can no longer be reused (without a complement). They should not have been used anyway, any of them, because none expresses, by itself, the underlying concept they want to represent.

Proposal

Let's step back and review. There is a certain degree of consensus in that three types of time values are required, each with the following function:

1. The first, to represent a specific position, point, or granule, in the line of time.
2. The second, to represent a specific segment of the line of time, between two specific instants.
3. The third, to represent the size of the second.

Perhaps, another type of time value may be necessary, one that contains the information needed to get from any instant to any other, toward the future or the past. But the usual has been to indicate the direction of movement allowing the third type to have a sign, which if positive points to the future and if negative, to the past, without requiring to create a new type which could be called TimeVector, with magnitude and direction.

Examining types two and three, it’s easy to see the conceptual difference between the two: The second is a "set" of instants and the third is the "cardinality" of such set. But none of the selected names express these two different concepts by themselves.

However, it is not easy to propose unambiguous names in an isolated manner yet expressive and comfortable enough to use both in programming language as in natural language (used for writing documentation and articles). Maybe it’s not possible to find a satisfactory name in both contexts.

However, it is clear that if in the natural language we can’t find a name that meets the rigor required by the technical language, we technicians are authorized to construct it. And as it has been shown that Interval, Period and TimeSpan are not suitable unambiguous technical names, I propose the following:

1. Instant: (a.k.a. Date, DateTime, Timestamp, TimePoint). Represents a position on the line of time. It may be explicitly granular, depending on implementation decisions.
    
2. TimeSpanBody: (a.k.a. ‘Time Interval’ in ISO 8601, ‘Period’ in SQL, ‘Interval’ in NODA, JODA and JSR 310). Represents a specific segment of the line of time, between two specific instants (StartInstant and EndInstant). It is not directional but can be traversed "form start to end" or "from end to start".
    
3. Duration: (a.k.a. ‘TimeSpan.Duration’ in .NET, ‘Interval’ in SQL). Represents the amount of time contained in a TimeVector or a TimeSpanBody. As a quantity, it is an unsigned value.
    
4. TimeVector: (a.k.a. ‘TimeSpan’ in .NET, ‘Duration’ or ‘Period’ in NODA, JODA and JSR 310). Represents the magnitude and direction of a shift on the representative line of time. Added to an Instant, it leads to another Instant. It may contain TimeParts of variable duration (such as years and months) that can only be reduced to fixed-duration units (seconds and its multiples and submultiples) when combined with an instant to produce a TimeSpanBody.

("Instant" and "Duration" are concepts applicable only in the context of time, for which ‘TimeInstant’ and ‘TimeDuration’ would be redundant names).

Points of Interest

With these fundamental time values, we can develop (I hope) all arithmetic and logic required to manipulate time values of any personal or business information system. Most of the complexity would be located in the "decorative" elements: Calendars, TimeZones, Daylight Saving Time (DST), Periodic Time Values (like time-of-day, day-of-month, and so on) applied to values.

Calling them "decorative" does not reduce its importance, but it changes the usual approach by the following:

Time values •are• universal but can be •presented• in many ways, depending on the selected culture and geographical location.

As such, we can relocate the complexity of the “Time Values” to the "Time Formats" and in turn get a simpler arithmetic devoid of pitfalls (as far as possible).

I would like to know the comments and suggestions of "those who code", "those who design" and "those who write".

History

• 7^th November, 2015: Initial version