Check out the screenshot above. By saying what time zone doesn’t apply for determining the date of the contract (New York time), it in effect says that Macau time (I assume) applies. It would have been clearer to say “(Macau time)” after the date of the contract, but that’s a quibble.
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.
It so happens that at ¶ 15.7, MSCD discusses such an internal rule: “All references to a time of day are references to the time in [location].”
Well, I think that doesn’t do enough. Let’s try this instead:
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].
I expanded it because one can state a point in time without mentioning a time of day, as in The Option expires on 4 April 2022. Same with periods of time, as in This agreement will terminate one year after the date of this agreement.
So I’d go with the internal rule instead of, or conceivably in addition to, specifying a time zone for the date of the contract.
[Updated 11:25 a.m. ET, 7 May 2022: I revised my proposed internal rule to say this: All references to time are based on the time in [location]. It’s more general than the current MSCD version, so it spares me having to get into gruesome detail like my original revised version.]
But the reference in the screen shot isn’t to time of day, it’s to the calendar date itself, so your language needs to be broadened even further. Reference: E. A. Poe, Three Sundays in a Week.
Are you sure? In my scenario, the date would be 1 December 2016, the date 30 November 2016 wouldn’t be included, and when 1 December 2016 occurs would be determined according to Macau time.
I partially agree with Vance Koven. IMO, the use of “time of day” before the comma might cause a reader (read: me) to believe that the rule stated after the comma will refer only to “time of day.” I checked Mirriam-Webster, and the definition of “time of day” means “the time as indicated by the clock.” But the rule after the comma covers both cases: (1) when only a date is specified; and (2) when a date and time are specified.
I recommend the following fix (or something similar) to ensure parity in both clauses (my change in bold):
Thank you, but that muddles things, and the first half would overlap with the second half. The second half is intended to cover language that doesn’t include a time of day, as in the two examples I give. The way to avoid any confusion would be to include the two examples.
I understand (and am now mildly embarrassed). How about this revision instead?
This makes clear that there are two cases (and hopefully, without requiring the need for examples).
I ended up making it two sentences. And I didn’t add examples. If time ever become an issue, I think it’s clear enough as is.
In general, there wouldn’t be a need to state time zones in the context of the date of the contract. But in the example provided, it looks like one party is in New York and the other party is in China. So they could be signing simultaneously while looking at each other on a Zoom call, and it would be different days, due to the international date line.
I would not add the second sentence to the existing MSCD text on the matter. Here’s why:
(1) One cannot specify a point in time without explicitly or implicitly mentioning a time of day. *Every* point in time occurs at some time of some day. The provision ‘The Option expires on 4 April 2022’ does not state a point of expiry because it does not state a point at all (unless there’s an interpretive rule that explains how to construe a point described as a period).
(2) Similarly, the phrase ‘the date of the contract’ does not state the point at which the contract takes effect, because it does not state a point at all, but a 24-hour period. ‘The Option expires one year after the date of this agreement’ is therefore ambiguous, with the most reasonable interpretation (in my view) being ‘one year after [midnight at the end of] the date of this agreement. I would insert the bracketed words or use an internal rule.
(3) The original problem of how to date a contract when one party is in Macao and the other in New York is readily solved by specifying the point at which the contract takes effect by date and time in a specified place.
(4) The underlying rule for drafters is ‘never use a *period* to describe a *point*’. You can tell a period from a point because a period has duration and a point doesn’t. A nanosecond has duration, so it’s a period, not a point.
(5) A drafter can keep substantive provisions regarding time simpler by doing the heavy lifting in the internal rules section. It takes a bit of care, though. For example, you can say ‘Clock times in hours and minutes refer to points, not periods’, but a clock time can fairly be deemed a one-minute period, so you’d have to specify further, perhaps like this: ‘By way of example, 12:01 a.m. means the point 60 seconds after the point that starts the day’. –Wright