Innovation That Matters

In this article I will explain the nuances of dates and times and how to reference them in contract text, and provide recommendations for how to make them computable for contract automation purposes.

Time is Complex

First, let’s get this out of the way — time is complex, and our reptilian brains struggle to understand it. The sun rises, the sun sets — and our circadian rhythms have evolved to regulate our physical and mental activity, and to provide a perception of a linear “time’s arrow“, from sunrise to sunset, day by day, from the past and stretching into the future.

However, people on different parts of the planet clearly perceive time differently; due to the curvature of the Earth their “days” start earlier or later than ours. Despite the best efforts of Isaac Newton, people in space (or satellites) really do age slower (time passes more slowly) than people on the surface of the Earth! Many in theoretical physicists have come to believe that time fundamentally does not even exist.

That said, for humans on the surface of the Earth (who are born, live and die), to communicate temporal concepts (coronations, marriages, births, deadlines, times to meet, periods between events) a written and spoken notation/language is required. It likely started simple, for example, “4 full moons ago”, and became more sophisticated. The predominant notation we use today (the Julian/Gregorian calendar, from the Roman Emperor Julius Caesar) is an amalgamation of influences and corrections from across millennia, cultures and civilisations. There are other notations still in use.

There are many falsehoods that people believe about time, and some of them will cause contractual issues. Here is just a small sample:

• There are always 24 hours in a day.
• February is always 28 days long.
• Any 24-hour period will always begin and end in the same day (or week, or month).
• A week always begins and ends in the same month.
• A week (or a month) always begins and ends in the same year.

Terminology

Some of the terminology around our time notation needs to be used quite precisely if we are to understand one another and to perform unambiguous computation. In the next section I take a quick tour (with references) through the major concepts.

Time Zone

A time zone is an area which observes a uniform standard time for legal, commercial and social purposes. Time zones tend to follow the boundaries between countries and their subdivisions instead of strictly following longitude, because it is convenient for areas in frequent communication to keep the same time.

Each time zone is described by an identifier and usually has the format region/city (Asia/Tokyo) and an offset from Greenwich/UTC time. For example, the offset for Tokyo is +09:00.

The goal is to align the start of the day with the rising of the sun, and the end of the day with the setting of the sun.

Zone Rules

Zone rules determine how an offset varies for a particular time zone. For example, most time zones experience a gap (typically of 1 hour) when moving the clock forward to daylight saving time, and a time overlap when moving the clock back to standard time and the last hour before the transition is repeated.

Time zones also change due to geopolitical events, and software systems have to maintain a database that maps from time zone identifiers to UTC offsets, and include information about daylight saving time changes.

As you can see below, UTC offsets at the poles get very complicated and arbitrary! UTC +13:00 anyone?

ISO 8601

ISO 8601 is a standard established by the International Organization for Standardization defining methods of representing dates and times in textual form, including specifications for representing time zones.

If a time is in Coordinated Universal Time (UTC), a “Z” is added directly after the time without a separating space. “Z” is the zone designator for the zero UTC offset. “09:30 UTC” is therefore represented as “09:30Z” or “0930Z”. Likewise, “14:45:15 UTC” is written as “14:45:15Z” or “144515Z”. UTC time is also known as “Zulu” time, since “Zulu” is a phonetic alphabet code word for the letter “Z”.

Offsets from UTC are written in the format ±hh:mm, ±hhmm, or ±hh (either hours ahead or behind UTC). For example, if the time being described is one hour ahead of UTC (such as the time in Germany during the winter), the zone designator would be “+01:00“, “+0100”, or simply “+01”. This numeric representation of time zones is appended to local times in the same way that alphabetic time zone abbreviations (or “Z”, as above) are appended. The offset from UTC changes with daylight saving time, e.g. a time offset in Chicago, which is in the North American Central Time Zone, is “−06:00” for the winter (Central Standard Time) and “−05:00” for the summer (Central Daylight Time).

Time Instant

Represents the start of a nanosecond on a timeline. A time instant does not have a duration, unlike say a minute, or a month or a day. A time instant cannot be located on the global UTC timeline, as we do not know where the event occurred (its time zone offset). Time instants are typically implicitly relative to a computer system or event.

Zoned Date Time

An ISO 8601 date+time that includes a UTC offset, or time zone information that allows the UTC offset to be calculated. This can be converted to a time instant but is also a point on the global time line, allowing Zoned Date Times to be compared: did event A happen before event B, or how many seconds elapsed between event A and event B.

Local Date

Local dates are frequently used in contracts and are a source of ambiguity and confusion. Dates without UTC offset deal exclusively with date information, without respect to time or time zone. They represents a year-month-day in the ISO calendar and are used to represent a date without a time. You might use such a “local date” to track a significant event, such as a birth date or wedding date.

Local dates do not represent points (or even periods) on the global time line. They are inherently ambiguous and dangerous to use in contracts because the reader of the contract may assume the dates are in UTC, the drafter’s timezone, their own timezone, or anything in between. In addition, if they are used to express deadlines or start dates, because of the missing time component, they are even more ambiguous.

Duration

A duration measures an amount of time using precise time-based values (seconds, nanoseconds). A duration of one day is exactly 24 hours long. A duration is most suitable in situations that measure machine-based time. A duration is measured in seconds or nanoseconds and does not use date-based constructs such as years, months, and days. A duration can have a negative value, if it is created with an end point that occurs before the start point. A duration is not connected to the timeline, in that it does not track time zones or daylight saving time. Adding a duration equivalent to 1 day to a Zoned Date Time results in exactly 24 hours being added, regardless of daylight saving time or other time differences that might result.

Period

A Period uses date-based values (years, months, days). These values do not have precise durations; their durations vary based on where they occur on a timeline. For example, a period of 1 day in November is not guaranteed to be the same number of seconds as a period on 1 day in April. A period of one day, when added to a Zoned Date Time may vary according to the time zone. For example, if it occurs on the first or last day of daylight saving time. If you were, for example, born in Australia, but currently live in Bangalore, this slightly affects the calculation of your exact age.

Now

Represents the current time instant, using the system clock and the default machine time zone; however it can be converted to a Zoned Date Time for if the location of the system clock is known, or assumed.

Contract Drafting

The great principle about time in contracts is to specify periods from point to point. A day is not a point in time, but a period of time, and ignoring that fact is the cause of almost all ambiguity about time in contracts.

https://www.adamsdrafting.com/the-date-that-is/

The Nuts & Bolts of Contract Drafting, From Basic to Advanced Topics by Vincent R. Martorana includes some good practical advice for how to reference dates/times/periods and durations in contracts.

References to time could be used:

• To reference the date of something or to give a date to something
• To specify a point in time
• To specify the beginning or end of a time period
• To apportion a quantity per unit of time
  • The Parties are party to a confidentiality agreement, dated June 16, 2015.
  • The term of the Lease commences on June 16, 2015.
  • The Consultant shall not disclose any Confidential Information for five
    years after the Expiration Date.
  • The Company shall pay the Employee a monthly incentive fee.

References to time at the start of a period:

• The Company shall perform the Services from June 16, 2015.
• The Company shall perform the Services after June 16, 2015.
• The Company shall perform the Services starting June 16, 2015.
• The Company shall perform the Services commencing on June 16, 2015.

References to time at the end of a period:

• The Company shall perform the Services until June 16, 2015.
• The Company shall perform the Services to June 16, 2015.
• The Company shall perform the Services through June 16, 2015.

Recommendations:

• Be explicit
  • The Company shall perform the Services commencing on (and including) June 16,
    2015.
  • The Company shall perform the Services through and including June 16, 2015.
• Include a time-of-day reference
  • The Company shall perform the Services commencing at 9 a.m. New York City
    time on June 16, 2015.
  • The Company shall perform the Services until the close of business on June 16,
    2015.

To validly make an election to purchase the ROFR Shares, a Stockholder (any such Stockholder, an “Electing Stockholder”) must provide an Election Notice to the Selling Stockholder within 10 days after such Electing Stockholder receives the Sale Notice.

Bad time period drafting

Suppose the Electing Stockholder received the Sale Notice at 8 a.m. on June 1. Can they provide a valid election notice at 8:30 a.m. on June 11?

To validly make an election to purchase the ROFR Shares, a Stockholder (any such Stockholder, an “Electing Stockholder”) must provide an Election Notice to the Selling Stockholder within no later than 5 p.m. New York time on the date that is 10 days after the date that such Electing Stockholder receives the Sale Notice.

Better drafting

And another example.

The term of this Agreement ends at 5 p.m. New York time on June 16, 2015; except that if, within 10 days of a Major Event, the Company provides notice of termination of this Agreement to the Consultant, then this Agreement will thereby terminate.

Bad drafting

This example contains two layers of ambiguity:

1. is the date on which the Major Event occurs included in the determination of the 10-day period; and
2. does the 10-day period precede or follow the occurrence of the Major Event (or both?)?

The term of this Agreement ends at 5 p.m. New York time on June 16, 2015; except that if, no later than 5 p.m. New York time on the date that is within 10 days of after the date on which a Major Event occurs, the Company provides notice of termination of this Agreement to the Consultant, then this Agreement will thereby terminate.

Better drafting

Other considerations

• Lack of explicit time zones can affect references to not only the time of day, but also the date.
  • Better to state, e.g., “New York City time” rather than EST (EDT?)
• If only a date is used, do all times of day during that date “count”?
  • (e.g., if a grantee can exercise an option “through and including June 16, 2015,” can the grantee exercise the option at 11:59 p.m. on June 16, 2015)
• When is the “close of business”?
  • The close of which party’s business?

Adams on Contract Drafting also has this to say about using time zones within contracts:

So, is it a good idea to say which time zone applies when determining the date of the contract? I think that’s too narrow a question, because the issue of which time zone applies could arise with respect to any reference to time—dates, points in time, periods of time, apportioning quantities per unit of time—in a contract between parties in different time zones or involving business conducted in different time zones. I think it would be simpler to address the issue with an internal rule of interpretation.

Contracts frequently need to include language that makes it explicit how time periods, or time points are calculated.

Adams on Drafting: Using a Time Zone When Stating the Date of the Contract

For example, here is some sample legal language that attempts to make explicit how time periods are calculated.

Calculation of Time Periods Unless otherwise specified, in computing any period of time described in this Agreement, the day of the act or event after which the designated period of time begins to run is not to be included and the last day of the period so computed is to be included, unless such last day is a Saturday, Sunday or legal holiday under the laws of the State in which the Property is located, in which event the period shall run until the end of the next day which is neither a Saturday, Sunday or legal holiday. The final day of any such period shall be deemed to end at 5 p.m., local time.

Law Insider: https://www.lawinsider.com/dictionary/calculation-of-time-periods

Or, again from Adams:

All references to a time of day are references to the time in [location]. When a point in time occurs and when a period of time begins and ends will be determined with reference to the time in [location].

https://www.adamsdrafting.com/using-a-time-zone-when-stating-the-date-of-the-contract/

And finally, a note about effective date for contracts:

It’s clearer not to use effective date (as a defined term or undefined) for the start of performance, because a contract is effective when it has been signed by all the parties. Consider using instead a term such as start date or performance date.

https://www.adamsdrafting.com/keep-separate-the-date-of-the-contract-and-timing-of-performance/

Summary

I would urge you to strive to make your references to dates, times, durations and periods within your contracts unambiguous and computable/comparable. You should include explicit language (see Adams above, for example) to make temporal statements clear and unambiguous so that contract performance can be objectively evaluated. Consider that not all parties to your contract may be in the same timezone, or have the same daylight savings time rules. Explicitly consider the difference between a time duration (24 hours) vs a time period (1 day, which may have 23, 24 or 25 hours).

Consider how you will use the dates and times within your contract downstream for search, query, reporting and automation.

As a rule-of-thumb I recommend:

• Use an explicit time zone or UTC offset for both dates and times
• Use an explicit time for dates, especially for deadlines
• Be explicit in how differences between dates and times are calculated
• Be explicit in the difference between temporal durations and periods, especially for highly automated contracts