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:

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