Martin Fowler talks about TimePoints

Martin Fowler:

The most common issue with time points is that they come at various levels of precision. When I say I'm writing this on August 28 2000, and I say I'm writing this at August 28 2000 2:33:34 pm, I'm saying two different things. One statement is to day precision, and other to second precision. Notice that the second precision is more precise than the day precision, but in this case happens to be less accurate. Any time point needs to know its precision so that you can answer questions such as did this event occur at the same time as another event.

The key point is that you can't rely on only on precision for most domains. Much of business is done at day precision. It doesn't matter when my phone request for transfer of funds occurs during the day, it's just processed according to the day I do it. Otherwise life could get very annoying. If I want to make a transfer the same day a bill is presented for payment, should I worry about exactly what time the bill is presented. Common business practice says no, if it was on the same day, I don't run the risk of going overdrawn or refusing the payment.

Right on! However, the correct technical term when speaking of time is resolution, not precision. Resolution is a matter of the capabilities of the syntax/notation used to represent a temporal value; precision is a matter of data quality. A clock that provides one-microsecond ticks has a resolution of one microsecond--but its precision may not be that high. [Which reminds me: I need to ask Doug Surber what he meant by "DateAndTime clockPrecision" when he put that method in the ANSI Smalltalk Standard's <DateAndTime factory> protocol. I've assumed he actually meant precision, and not resolution.]

Chronos provides YearMonthDay, whose resolution is one civil day, and Timepoint, whose resolution is one nanosecond.

YearMonthDay instances aren't bound to time zones--they have nominal time invariance. Timepoint instances can either be bound to a time zone and have Universal Time invariance, or they can have nominal time invariance and not be bound to any time zone.

As Martin points out, choosing the time-invariance semantics that is right for each situation is of no small importance:

Another tricky area with time points is how to handle time zones. In a similar way with precision, there is no right answer for all applications. Sometimes you'll want a time point with a time zone, sometimes not. A timepoint without a time zone is perfectly sensible, it means within the local time of it's context. You find these where further time zone information is either not useful, or can be obtained from it's context. Be wary of using time zones when you don't need it.

Also be wary of not using time zones when you do need them.

Martin also advises against using temporal intervals as TimePoints. He's absolutely correct. Squeak's Chronology library makes this mistake.

Many other date/time libraries use a model of time that assumes that TimePoints have infinite resolution--which is a different aspect of the same conceptual error (e.g., Joda-Time's concept of the "Instant".) But there is no such thing as infinite resolution--not even in Physics. Such mistakes lead to ugly code, awkward APIs, poor architecture--and perhaps even wrong results.

---

• Chronos blog home page
• Chronos Date/Time Library web site