Issues for Mailing list of the Date-Time (DTV) Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 16659: Date-Time issue: Specification Should Contain List of Date-Time
Issue 16660: Date-Time Issue - Need Inventory of SBVR Terms
Issue 16661: Date-Time Vocabulary - terms for referenced vocabularies
Issue 16662: Date-Time Issue - OCL Corrections
Issue 16663: "Law of Monogamy" example is poorly stated
Issue 16664: Date-Time Issue: Propositions, Situation Models, and Occurrences
Issue 16665: Date-Time Issue - granularity appears twice
Issue 16666: Date-Time Issue - Definition of "Situation Model"
Issue 16667: Minor Errors in Duration Value Verb Concepts
Issue 16668: time scale1 differs from time scale2 by time offset
Issue 16669: Date-Time Issue - local time
Issue 16670: Date-Time Issue - week of year
Issue 16671: Date Time Issue - time set2 is duration after time set1
Issue 16672: Date-Time Issue - time of day
Issue 16673: Date-Time Issue - missing arithmetic on time point sequences
Issue 16674: Date-Time Issue - Atomic Quantity Value Conversion
Issue 16675: Date-Time Issue - Arithmetic Involving Years and Weeks
Issue 16676: Date-Time Issue - scale has scale point
Issue 16677: Date-Time Issue - Formulating Tense and Aspect
Issue 16678: Date-Time Issue - states of affairs and situation models
Issue 16679: Date-Time Issue - Examples Related to Timezones
Issue 16680: Date-Time Issue - leap seconds
Issue 16681: Date-Time Issue: Gregorian calendar introduction
Issue 16682: Date-Time Issue: Time Zones
Issue 16689: D0 Should be Quantified
Issue 16690: CLIF Logic Errors
Issue 16714: Date Time Issue: quotation in OCL of UML symbols that include blanks
Issue 16715: Date-Time Issue: CLIF file should include metadata
Issue 16716: Date-Time Issue: OCL should be integrated into UML model
Issue 16717: Date-Time Issue: now is not synonymous with current
Issue 16719: Date Time Issue - compound quantity value cardinality mismatch
Issue 16768: Relating time to states of affairs
Issue 16869: UML packages don't match specification sections
Issue 16870: Relationship of UML model to SBVR is undocumented
Issue 16872: Annex D should be Normative
Issue 16873: UML operations are not defined
Issue 16874: Clause 5.2 depicts the UML model as informative
Issue 16921: ISO 80000 & Date/Time Foundation Vocabulary
Issue 16934: Need Informal Definitions or Descriptions
Issue 16935: Between
Issue 16943: Calendar day is misdefined
Issue 16944: Weekday definitions are inadequate
Issue 16949: DTV Editorial issue: Figures 9-5 and 9-7 should be reversed
Issue 16951: Time point subdivision is out of place twice
Issue 16990: Mischaracterized description of 'properly overlaps' in text
Issue 16992: Corollaries to Axiom D.4 in 8.2.3 are misstated
Issue 16993: no syntax for indefinite time periods
Issue 16997: forever is misdefined
Issue 17128: UML Model Should be Vendor-Independent
Issue 17129: Need Profile for UML Stereotypes
Issue 17225: DTV Issue: inaccurate formulation of definitions in CLIF
Issue 17227: Description of time point conversion is confused
Issue 17232: DTV time-of-day time point definitions are inaccurate
Issue 17349: spec should provide a simple library of datatypes for use in UML and data modeling
Issue 17367: DTV Issue: There is no smallest time interval
Issue 17404: Quantity Kind is a categorization type
Issue 17425: rename 'calendar date'
Issue 17426: UML vs. text inconsistencies in clause 12
Issue 17427: Confusing text for Gregorian calendar
Issue 17428: basic time coordinate concepts are badly described
Issue 17429: Definition of Calendar Date
Issue 17431: "General Concept" for "Time Axis" should be "Definition"
Issue 17446: DTV Issue: A calendar day is not a time period
Issue 17465: Duration vs. Duration Value
Issue 17533: Year of Weeks and Year of Weekdays Scales are Misdefined
Issue 17540: Need to support infinite and indefinite time constructs
Issue 17541: Inconsistent Use of ‘Concept Type’
Issue 17555: 'Gregorian Month' Confused with 'Gregorian Month of Year'
Issue 17556: 10pm to 2am does not specified a time period
Issue 17573: time-of-day time point definitions are inaccurate
Issue 17593: Reference to 'conceptual schema'
Issue 17594: Next Sequence Position
Issue 17595: 'Time Span' is defined twice
Issue 17597: repair heading structure of Clause 16
Issue 18130: Conflicting models of 'leap second'
Issue 18167: ‘Time of Day’ misused
Issue 18173: Adopt ‘occurrence’ and ‘what-happens state of affairs’ from SBVR
Issue 18187: Definition of 'time interval is current'
Issue 18189: invalid indexical time references
Issue 18190: Time Point Converts to Time Point Sequence
Issue 18191: time point1 shares common time scale with time point2
Issue 18240: Clause 8.3.2 dependency upon clause 10.2
Issue 18241: time interval1 precedes time interval2
Issue 18253: Time intervals defined by duration
Issue 18283: Atomic Time Coordinate has Index
Issue 18284: UML Profile is Specifically for DTV, not for SBVR in General

Issue 16659: Date-Time issue: Specification Should Contain List of Date-Time (date-time-ftf)

The specification should contain a formal list of all the SBVR vocabularies defined by the specification. An example of such a list is given in SBVR clause 7.  The list is needed by software that converts the specification text to XMI.

The specification should contain a list of the SBVR terms and verb wordings that are referenced in the document, in order to make it clear where these terms come from.

Proposed text for clause 4 "Terms and Definitions":
__________________________________________________
SBVR Meaning and Representation Vocabulary
General Concept:	vocabulary
Language:	English
___________________________________________________
concept
concept1 specializes concept2
concept type
fact type
fact type has fact type role
fact type role
integer
instance
meaning
meaning corresponds to thing
meaning has representation
name
non-negative integer
noun concept
number
proposition
representation
representation uses expression
role
set
statement
statement expresses proposition
term
text
thing
thing has name
thing is in set
Synonymous Form:	set includes thing
Synonymous Form:	set has element
thing1 is thing2
verb concept
__________________________________________________
__________________________________________________

__________________________________________________
Vocabulary for Describing Business Vocabularies
General Concept:	vocabulary
Language:	English
___________________________________________________
categorization type
res
terminological dictionary
vocabulary
vocabulary namespace

The start of clause 7 has a set of SBVR terms for referenced vocabularies.  The following are missing from this list:

IKL
Definition:	The proposal of the IKRIS Interoperability Group, entitled IKL Specification Document, available at http://www.ihmc.us/users/phayes/IKL/SPEC/SPEC.html
Inter Gravissimas
Definition:	The papal bull issued by Pope Gregory XIII, 24 February 1582. Prepared in English, Latin, and French by R.T.Crowley for ISO TC154 on 27 December 2002.
ISO 18026
Definition:	The standard of the International Standards Organization (ISO), number 18026, Information technology — Spatial Reference Model (SRM), 2009
ISO 80000-3
Definition:	The standard of the International Standards Organization (ISO), number 80000-3, named: Quantities and units -- Part 3: Space and time, 2006
OCL
Definition:	The specification of the Object Management Group (OMG) named: Object Constraint Language, version 2.0, May 2006

The OCL text throughout the specification needs to be checked for consistency against the UML diagrams. The following places were specifically noted in the submission document as requiring review:
•	The OCL definition for "time interval1 plus time interval2 is time interval3"
•	The OCL definition for "time interval1 to time interval2 specifies time interval3"
•	The OCL for the Axioms under "duration3 equals duration1 plus duration2", " duration3 equals duration1 minus duration2", "duration2 equals number times duration1"

Regarding the "monogamy" example in clause 7.3
> “Consider the law of monogamy as it exists in some countries:”
> “It is prohibited that a person1 is married to person2, if that person1 is married to another person3 and person2 is different from person3.”
> “This rule is not entirely correct….”
I cannot imagine a country with the law of monogamy stated like that.  It is not proper English nor is it proper SBVR SE.  How about this: “A person must not be married to more than one person.”  This section argues that the rule statement is “not entirely correct” because it doesn’t say “at the same time”.  But that is nonsense.  Based on that argument, every rule would need to explicitly tie every relation it uses to time.  E.g.:
Rule A:  It is prohibited that a drunk driver operate a EU-Rent vehicle.
Rule B:  It is prohibited that there exists a time interval such a driver is drunk throughout that time interval and the driver operates a vehicle throughout that time interval and the vehicle is a EU-Rent vehicle throughout that time interval.
It would be better to point out that in any situation there is at most one present time.  Therefore, the law of monogamy stated as “A person must not be married to more than one person” is perfectly correct and it logically implies that “A person must not be married to more than one person at the same time.”
 
“occurrence” is defined in the introduction to be a possible state of affairs.  This is OK, if that’s what is intended.  But “occurrence” is defined differently later.

Proposed Resolution:
Change the text at the start of the clause from:
Consider the law of monogamy as it exists in some countries:
It is prohibited that a person is married to more than one person.
This rule is correct only on the understanding that the rule is evaluated at a point in time, as specified in this document. A version of the rule that uses the concepts defined in this section to make this understanding explicit is:
If a person1 is married to some person2 occurs for some time interval, it is prohibited that person1 is married to another person3 during the time interval.

to:
Consider the law of monogamy as it exists in some countries:
It is prohibited that a person is married to more than one person.
This rule is correct only on the understanding that the rule is evaluated at a point in time, as specified in this document. A version of the rule that uses the concepts defined in this section to make this understanding explicit is:
If a person1 is married to some person2 occurs for some time interval, it is prohibited that person1 is married to another person3 during the time interval.

Comments about section 7.3.6, "Propositions, Situation Models, and Occurrences"
> “This is because many propositions describe a single situation
> (a "general situation model") that may have multiple occurrences.”
The paragraph containing this statement and the paragraph above are reworded by Mark.  But this statement remains unchanged.  If the statement is about a single general situation model, then it should not say “single situation”.  Situations are not models.  On the other hand, if it is about the single situation, it would be more clear to say that where a proposition corresponds to a single situation, that situation might occur at various other times than at the current time of the world for which the truth of the proposition is being considered.  
 
> “For example, the proposition "rental car 123 is inspected", using a fact
> type "rental car is inspected", describes multiple occurrences if the rental
> car is inspected more than once.”
This is from Mark’s rewrite of paragraph 2.
The problem with the statement is that the proposition given as an example does not fully describe occurrences.  It describes a circumstance that is included by multiple occurrences.  Each of the occurrences is a situation that includes Rental Car 123 being inspected and that further includes some other circumstance that distinguishes one occurrence from the others, such as it being a certain time.  It could be said that the proposition partially describes those occurrences.
 
> “In a temporal world, a logical sentence need not be true or false; it can be 
> sometimes true and sometimes false, and therefore neither true nor false.”
This statement presumes the temporal world has no past/present/future.  A “logical sentence” that is an interpretation of a natural language sentence about a world is considered to be true or false with respect to the current time in that world.  Tense is used when describing past or future situations.  There is no need to abandon truth-functional logic when temporal concepts are used.  Indeed, time concepts are used widely and effectively in logic systems where “logical sentences” are either true or false, and never both, with respect to any world. 
 
> “For example, the proposition "activity A precedes activity B for a given order" …”
This is unclear.  But it might demonstrate the point made at the end of the same paragraph that the Date-Time submission might be misusing SBVR’s concept ‘proposition’.  A more clear example would help us understand whether there is misuse or not.
 
> “… each of the occurrences of John actually writing a book.”
These words from an example in 12.3.6 (and similarly in 12.3.1) illustrate something missing from the Date-Time submission that, if provided, would help it to align with SBVR.  According to the submission, there are occurrences of “John actually writing a book”.  But the actual writing of a book by John is not a model.  There are multiple occurrences of it and it is not a model, but an activity (a kind of state of affairs, or what Date-Time calls a “situation” in its clause 5.9).  The Date-Time submission does not provide a fact type to relate a temporal occurrence to the activity, situation or circumstance that has the occurrence.  That is unfortunate.
 
> “Brazil wins the FIFA World Cup.”
> “…both true and false, or neither, in a world that includes all of
> the last 20 years.”
The example under ‘proposition describes occurrence’ starts with an ambiguous statement.  It is in present tense, so it either means that the winning is happening presently (the news bulletin at the final horn) or, by another interpretation, it means that Brazil wins from time to time: winning the FIFA World Cup is something that Brazil does.  A world in which the current year is 2002 includes 1994 being in the past and excludes 1994 being the current year.  The final statement describing the example seems to describe a world in which the present year is all of 20 different years, which is impossible.  A possible world has one past, one present and one future.  If the Date-Time submission abandons that fundamental idea, then it is no wonder that they claim that propositions are “both true and false, or neither”.  It would be best to have a clear example and separates the ideas of whether a situation has been or will be actual from whether it is actual in the world under consideration.  The truth of a proposition is based on whether the state of affairs to which it corresponds is actual.  It is not based on how many times that state of affairs has occurred in that world’s past or will occur in that world’s future.  I am not arguing against the fact type, ‘proposition describes occurrence’, which relates a proposition to occurrences across time.  I am arguing against using a bad example to create confusion about how propositions are true or false.
 
> “The situation model is the bindable target of an objectification…”
I recall that there was already agreement to remove the statement above.  Related notes were already corrected.  A situation model is not a bindable target unless it is one of these:  an individual concept, a variable or an expression.  Also, a situation model is not a referent of a bindable target of an objectification unless it is a state of affairs.
 
> “The proposition “John is writing a book” is true during the time periods of each of the occurrences of John actually writing a book”
The proposition is true if John is writing a book.  That’s all.  The situation of John’s writing a book is actual if John is writing a book.  That situation might be actual at different times, but other propositions would refer to those other times.  E.g., “John was writing a book in 2010”, which is true or false on its own – that’s a different proposition.  The primary failure in the thinking behind this section is the failure to recognize that a proposition corresponds to just what the proposition proposes and no more.  The explanation of the example fails to explain how occurrences are distinguished, and therefore, fails to show how the proposition “John is writing a book” describes any of them other than that it describes one circumstance included in each of them.  The proposition gives no indication of whether occurrences are distinguished by book (if John is writing multiple books, perhaps simultaneously) or by place (if writing on different devices) or by contiguous time interval (if John interrupts writing to eat dinner).  Perhaps the verb phrase should be changed to “indefinitely describes” or “partially describes”.

Proposed Resolution:
(These changes were adopted by the submission team after the final submission.  They are recorded in this Issue for reconsideration by the FTF).

Replace the first two paragraphs of 7.3.6 with the following:
In a possible world that has no notion of time, there is a 1-to-1 relationship between propositions and states of the possible world:  A proposition is true if the state it describes is the state of that world, and it is false if the state it describes is not the state of that world. SBVR truth semantics reflect this model.
When temporal concepts are introduced into the formal logic model, a distinction must be made between two aspects of the SBVR concept ‘proposition’ – a 'meaning' that is either true or false, and that corresponds to at most one situation. This is because many propositions describe a single situation (a "general situation model") that may have multiple occurrences. For example, the proposition "rental car 123 is inspected", using a fact type "rental car is inspected", describes multiple occurrences if the rental car is inspected more than once.

Under "proposition describes situation model":

Delete the Definition that reads " The situation model is the bindable target of an objectification that considers a closed logical formulation that means the proposition."

Delete the Example that reads " The proposition “John is writing a book” is true during the time periods of each of the occurrences of John actually writing a book."
Change the date in the Example that reads " It is true in the world of 1998 ..." to read "1994".

The term "granularity" has two glossary entries, one in clause 8.2, and another in D.4.  One should be renamed to avoid confusion, although they mean almost the same thing.
Proposed Resolution:
(The submission team adopted this resolution after the final submission. The change is recorded here as an Issue so that it can be considered by the FTF.)

Under "time scale has granularity" in clause 8.2, add a new Necessity:

Necessity:	The scale of the time scale is the granularity of the time scale if and only if the granularity of the time scale is a precise time unit.
In Annex E.3:

•	rename the glossary entry "granularity" to "scale granularity"
•	rename the glossary entry "scale has granularity" to "scale has scale granularity"
•	reword the Necessity under " scale has scale granularity" to read:

Necessity:	Each scale has at most one scale granularity.
•	Add 1 note and 2 examples:
Note:	Time scales are kinds of scales, but time scales of nominal time units (which are not true measurement units) do not have true scale granularities (which are always measurement units).
Example:	The Gregorian years scale has a granularity of 'year'. This granularity is the scale granularity of the scale.
Example:	The Gregorian months scale has a granularity of 'month'. This scale does not have a scale granularity because 'month' is a nominal time unit, not a precise time unit.

The definition of "situation model" should be clarified to make it clear that it "may or may not occur".

Proposed Resolution:
(At it's conference call on September 9, the submission team agreed to the following change. Since this change was after the final submission, it is recorded here for consideration by the FTF.)

Change the Definition of "situation model" to read:

Definition:	res that is an abstract model or conceptualization of an event, activity, situation, or circumstance that may or may not occur in some possible worlds

•	The fact type form “months centennial quotient of month value” is used in two different glossary entries in clause 10.6, “Duration Values”. The second entry should be “months quadricentennial quotient of month value”. Both the glossary entry and the definition should be updated.
•	The fact type form “years centennial quotient of year value” in clause 10.5 has the same error as above and needs the same fix.

concept "time scale1 differs from time scale2 by time offset" in clause 8.5.4 "Time Zones":

Issue:	This verb concept needs to be reconciled vis-à-vis "calendar1 differs from calendar2 by time offset" in clause 16.5.
Issue:	'Time offset' is defined above with reference to calendars but is used here as the difference between time scales.
The same concerns were raised under the glossary entry for "calendar1 differs from calendar2 by time offset" in clause 11.5:

Issue:	'Calendar has time offset' is not defined anywhere.
Issue:	Reconcile this verb concept vis-à-vis 'time scale1 differs from time scale2 by time offset' in clause 13.5.2.
The following issue came after the glossary entry for "date time coordinate with time offset" in clause 11.5:
Rework the definitions given above once we work out the "differ" relationships between calendars or time scales.

The final submission document recorded the following issue regarding the concept " local time" in clause 8.5.4 "Time Zones":

Issue:	"standard time of day" is not defined anywhere, and "standard time" is a time scale, not a time coordinate (as is "time of day").  "Standard time" and "local time" should be "time of day time scales" (e.g. time of day scales parallel to calendars).

The final submission document recorded this issue regarding the concept "week of year":

Issue:	This concept (and also 'weekday of year', 'year of weeks', and 'year of weekdays' are really about relating the weeks scale to the Gregorian calendar.  Consider whether these concepts should be moved into the section that describes the Gregorian calendar.

The final submission document recorded the following issues about these verb concepts:

Immediately under the glossary entry "time set2 is duration value after time set1":
Issue:	Should the second role be 'duration' instead of 'duration value'?
Under the Definition for that entry:
Issue:	This is not quite right, because we do not have a verb concept that adds durations to time point sequences.
And similarly, immediately under the glossary entry for "time set2 is duration value before  time set1":
Issue:	Should the second role be 'duration' instead of 'duration value'?
Under the Definition for that entry:
Issue:	This is not quite right, because we do not have a verb concept that subtracts durations from time point sequences

This issue was recorded in the final submission document regarding the concept "time of day":

Issue:	Consider whether "time of day" is a separate concept from "time of day coordinate".

This issue was recorded in the final submission document, under the entry for "Gregorian month converts to time point sequence on the Gregorian days scale":
Issue:	We have not defined arithmetic on time point sequences.

The final submission document recorded the following issue under the OCL Definition for "atomic quantity value1 is atomic quantity value2 converted to measurement unit":
Issue:	These definitions are inadequate because they depend upon "quantity1 = quantity2" which is not defined. We need the concept "quantity value1 is equivalent to quantity value2".

The final submission document recorded this issue in clause 11.6 "Mixed-Base Arithmetic":
Need to add a paragraph discussing arithmetic involving weeks and years because these are incommensurable. This depends upon defining a concept that computes the number of weeks in any particular year.

The final submission document recorded this issue regarding figure 80 "Scales" in clause Annex E.3:
The "black diamond" and {redefines...} on the "scale has scale point" association are wrong.

The final submission document recorded the following issue at the start of Annex F.5 "Formulating Tense and Aspect":

This section needs to be updated to reflect the term "situation model" as used in this specification, instead of "state of affairs".

During the development of the submission, the submission team could not reconcile its requirements against the SBVR "state of affairs" and related concepts. The submission team resolved this problem by developing its own "situation model" approach. It assumed that the "situation model" design would be a stand-in for a better long-term design agreed with the SBVR RTF.

The issue is highlighted by these two paragraphs that were in the submission and which the Architecture Board asked to have removed from the specification:

•	In clause 7.3 introduction, "Temporal Concepts for Situations":

" Note:  This specification introduces the concepts 'situation model' and 'occurrence' in order to present a complete and self-consistent vocabulary. SBVR has similar concepts 'state of affairs' and 'actuality' but, to date and after discussion with the SBVR RTF, the Date-Time submission team does not understand how to relate the Date-Time concepts with the existing SBVR concepts. The most pressing concern that Date-Time has with SBVR is that it is unclear how to relate a single proposition to multiple occurrences."

•	In the clause 7.3.6 introduction:

" NOTE:  In this section, situation model is said to be a specialization of the SBVR concept 'res', i.e., a thing that is not a 'meaning'.  This is to distinguish 'situation model' from both SBVR 'concept' and 'proposition'.  This specification treats the situation model as a thing in its own right, even though it is an abstraction, and relates it to occurrences by 'occurrence exemplifies situation model', rather than by SBVR 'meaning corresponds to thing'.  It is worth noting that this specification may be misusing the SBVR concept 'proposition', for the reasons discussed above."
The SBVR RTF has been considering a number of formal Issues raised against SBVR regarding "state of affairs".  The SBVR RTF has committed to addressing these issues in the SBVR RTF 2 by February 28, 2012. Once those Issues are resolved in the SBVR RTF, then this Issue should be addressed in the Date-Time FTF.

(This comment came from the Architecture Board's review of the final submission.)

The later sections of the specification (13.5.4 & 16.5) contain very detailed discussion of Time Zones and Daylight Saving Time. However, some of the earlier sections contain informal comments that don't always take this into account. For instance, on page 45 (clause 7.1.2) it says "Example: The time interval identified by 2010 is before the time interval identified by 2011." This glosses over the fact that 2010 and 2011 overlap by 24 hours, because 1 Jan 2011 was almost over in New Zealand before 1 Jan 2011 started in Hawaii. It might be worth quickly scanning all the examples, and perhaps amending language in some to take account of Time Zones.

(This comment came from the Architecture Board's review of the final submission.)
This comment on page 16 [now Annex A.3 jarred somewhat:
"These variations are accounted for by incorporating intercalary leap days and leap seconds into some calendar and timekeeping schemes. This specification chooses to support leap days, but not leap seconds, because leap days are significant to business while leap seconds are insignificant."
It seems a bit arrogant to assert that "leap seconds are insignificant to
business". If (for instance) your company's Telephone PABX were to crash at
midnight on New Year's Eve because its software couldn't cope with
leap-seconds, I suggest that would be "significant to business".

(This comment came from the Architecture Board's review of the final submission.)

On p100 it is stated that "the Gregorian Calendar was introduced in
1582" and corrected calendar drift by "skipping over the dates between
October 5-15, 1582". This is true, but it's worth noting that only Spain, Portugal, the Polish-Lithuanian Commonwealth, and parts of Italy implemented the new calendar on Friday 15 October 1582 (following Julian Thursday 4 October 1582). Other countries stayed with the Julian calendar, so those "lost dates" (e.g. 10th October 1582) are valid in those countries. France adopted the Gregorian calendar on Monday 20 December 1582 (following Sunday 9 December 1582). Other countries followed over the centuries, with the UK and East-Coast American colonies not switching until 1752 (Wednesday 2 September 1752 was followed by Thursday 14 September 1752). Russia didn't change until 1918. The last countries to change seems to have been Greece, where Thursday 1 March 1923 followed Wednesday 15 February 1923, and Turkey, which switched in 1926.

(Yes, I got all those dates from Wikipedia :-).

Hence I think this section would benefit from a comment saying that although the Gregorian Calendar begins in 1582, various countries switched on various later dates, so that to be completely unambiguous, dates after October 1582 should really state which calendar they use. (For instance, today, Sunday 11th September 2011 in the Gregorian Calendar is Monday 29th August 2011 in the Julian calendar).

Similarly, at the top of page 121 it says that the Gregorian calendar was "introduced in 1582". It might be more accurate to say it was "first defined" in 1582 (or some similar wording), and "introduced" in different countries at different later dates.

13.5.4  "When there are two calendars for a time zone, one is standard time and the other is daylight savings time. The dates and time of day for changing between them is determined by local authorities for each time zone."

Said authorities do, on occasion, change not only the dates and time of day for changing between local calendars, but the time offsets that apply within a locale.  I would like to see the example that demonstrates how this specification would be used to reason coherently about events both prior to and after such a time zone transition in a continuously operating system (no big-bang updates allowed).

Comment #2

The Annex B references do not include the Zoneinfo database, ftp://elsie.nci.nih.gov/pub/, http://en.wikipedia.org/wiki/Tz_database.

(Zoneinfo handles the situation mentioned in Comment #1 by making the locale identifier be the primary key.  For example, if your time zone is America/New_York, then the different rules for Daylight Savings Time before and after the 2007 changeover are implicit in any conversion between local time and universal time.)

Clause 7.2.2 has several CLIF axioms that reference 'D0' but fail to quantify that variable.  They should each existentially quantify 'D0'.

Various logical errors in the CLIF axioms need correction:

1.	In clause E.1.2, the axiom under concept "sequence is of concept" reads:

(forall ((member thing) (s sequence))
 (exists ((c concept))
  (iff ("sequence is of concept" s c)
       (if "member participates in sequence" member s)
        ("concept corresponds to instance" c member)))))

and should probably read:

(forall (s sequence)
 (exists (c concept)
  (iff ("sequence is of concept" s c)
    (forall (member thing)
       (if ("member participates in sequence" member s)
           ("concept corresponds to instance" c        
            member))))))
2.	Several of the verb concepts in clause E.1.5 range specifically over "unique sequences".  In several cases, the axioms are not written to match the concept types that the roles range over.

During the Architecture Board's review of the final submission, Pete Rivett asserted that the document quotes UML symbols incorrectly when they are referenced in OCL statements. When a UML symbol includes a blank or other special character, the final submission wraps the symbol with double-quote characters.  Peter Rivett says that UML has adopted another quoting mechanism.  We need to check the UML standard and also what the tools actually support.

The machine-readable CLIF file contains the CLIF axioms mechanically stripped out of the specification document.  Currently, it is very difficult to trace back from the individual CLIF file entries to the matching source entries in the document.  The CLIF file should include metadata (presumably as annotations) that relate each axiom to the appropriate place in the document.

Currently, OCL statements are created directly in the specification document, then "stripped out" of the document into a separate file via an XSLT transform.  In a further step, the OCL should be integrated into the UML model so that the model includes the OCL constraints.

There are some terms that map to the same underlying concepts, but they are not synonymous because one cannot be substituted for the other.  Often this is a matter of how they fit into context as being relative or not.  In particular:
a.  “now” is not synonymous with “is current”
b.  “today” is not synonymous with “current day”
c.  “tomorrow” is not synonymous with “upcoming day”
d.  “yesterday” is not synonymous with “previous day”
Proposed Resolution:
(The submission team adopted these changes after the final submission.  They are recorded here so that the FTF team can reconsider them.)

Make these changes in clause 9.2:
•	Insert the article "the" in front of the Definition of "time interval is current"  so that the Definition reads: "the time interval includes a time interval1 that is past and includes a time interval2 that is not past"
•	Add a new glossary entry:
time interval is now
Definition:	the time interval overlaps the time interval of utterance
Note:	"Time interval of utterance" means the time interval when a proposition is given, as opposed to when the proposition is evaluated.

The following actions are pending, from the minutes of the submission team conference call on September 9, 2011:
•	Distinguish “today” (and similar concepts) from “current day”.
•	Make sure all fact type definitions use the appropriate style
•	Find and fix relative times that are styled as individual concepts but aren't.
•	Clarify note under “day” to make it clear (if it isn't already) that we ignore leap seconds.

A Necessity under "compound quantity value has atomic quantity value" in Annex D.2.3 says:

Necessity:	Each compound quantity value has at least two atomic quantity values.

I believe this is correct.

Problem: the UML diagram in figure 79 at the start of Annex D.2.3 shows cardinality "1..*" at the "atomic quantity value" end of the corresponding association.

The Date-Time specification has verb concepts defining temporal relations to states of affairs that occur once, but not to states of affairs that recur.  This means that the Date-Time specification cannot support all the needs of business concepts systems that are based on typical business language.  The problem has also led to some erroneous formulations within the specification itself.
The relations to time include tense, aspect, duration, relations to time intervals (throughout/within/for/at/before/after <time interval>) and relative temporal positioning (before/after). They are defined for only the subset of states of affairs called “occurrences” and so are not helpful to semantic communities and businesses that refer to states of affairs more generally. 
Discussion:
A common conceptualization approach is to objectify states of affairs, making them the subjects of verb concepts represented by adverbs, adjuncts and other verbal clauses. That approach, which often refers to states of affairs as “events”:
•	does not limit states of affairs to being in the subset that the Date-Time submission calls “occurrences”, but uses objectification generally for any event, activity, situation or circumstance;
•	is seen in modern language processing systems and their lexicons;
•	is a mainstream approach in the field of computational linguistics;
•	is a recommended approach in text books on mapping language to logic.
Whether a situation can recur across time depends on how the situation is identified, which is a conceptualization decision chosen by a semantic community. A situation that is identified without regard to time (e.g., the situation of a given person’s being in a given location, identified by person and location) can recur. The same situation occurs twice if the same person is in the same location twice.
Most verb concepts do not have roles that range over time, so their instances are identified independently of time. E.g., each instance of the verb concept ‘person is in place’ is identified by a person and a place. These instances are not “occurrences” as defined by the Date-Time specification because they can obtain at multiple different times. The same person can be in the same place multiple times.
The problem is illustrated in the following examples:
1.	Consider the situation of there being snow in Seattle and a statement that the situation has occurred in the past, is not occurring now, and will occur in the future. The Date-Time vocabulary cannot be used for the three temporal relations in that statement; it includes a means to express such temporal relations, but not for situations that recur. An earlier version of the Date-Time submission supported this capability.
2.	Consider the same situation of there being snow in Seattle, and that the situation occurred throughout both 12/25/2008 and 11/25/2010. “Throughout” from the Date-Time vocabulary cannot be used to say so. The Date-Time vocabulary does not define “throughout” generally for states of affairs (which includes situations). An earlier draft of Date-Time supported this capability.
3.	It may be required to relate the same situation to its different occurrences. Date-Time defines “occurrence”, but does not provide the relationship between a state of affairs, such as the situation of there being snow in Seattle, and its separate occurrences. The Date-Time specification needs a verb concept by which a state of affairs can be related to its (possibly multiple) occurrences across time: ‘state of affairs has occurrence’.
4.	In describing aspect and tense, the Date-Time specification shows incorrect formulations for some cases, partly because it does not relate states of affairs generally to time. Several specified formulations include “the occurrence (that John writes a book)”. But “that John writes a book” is a state of affairs that can recur – it does not qualify as an “occurrence”. 
Also, some of the formulations should use nesting, but don’t. E.g., “John will have written a book”, which is misformulated in the Date-Time table on tenses and aspects, can be properly formulated using nesting: “the occurrence (that the state of affairs (that John writes a book) has occurred) will occur”.
If the Date-Time specification is finalized without resolving these concerns, semantic communities will have to create their own temporal concept systems (or find another standard) in order to relate states of affairs generally to time. Those concept systems could adopt basic time concepts from the Date-Time specification, but would also need concepts for relating time to events, activities, situations and circumstance - and would not find them in the Date-Time specification. This would be an unfortunate shortcoming of the Date-Time specification.
SBVR’s usual practice is to objectify states of affairs in order to make them subjects of verb concepts, and to nominalize propositions only when propositions themselves are the subjects of discourse. This enables a first-order logic interpretation when discourse is about states of affairs and not about propositions.  The Date-Time specification must also support this practice. There is a notion indicated in the Date-Time specification that propositions can be nominalized in order to relate states of affairs indirectly to time. People who want to nominalize propositions can, of course, do so but they need to be aware that doing so requires a problematic, higher-order approach. 
Regardless of anyone’s interest in nominalizing propositions, states of affairs are commonly objectified in business discourse (such as in business rules) and are referenced by common terms (such as “situation”, “event”, “circumstance” and “activity”). If the Date-Time specification is to be used for business discourse, it needs to provide for relating time to states of affairs generally.
Resolution:
A resolution should provide verb concepts for relating states of affairs to time.  A survey of business rules acquired from “business rules practitioners” shows that the following verb concepts will meet common needs for relating states of affairs to time.
The following verb concepts should be provided:
•	state of affairs occurs throughout time interval
•	state of affairs occurs within time interval
synonymous form: state of affairs occurs during time interval
•	state of affairs occurs for time interval
•	state of affairs1 occurs before state of affairs2 occurs
synonymous form: state of affairs2 occurs after state of affairs1 occurs
•	state of affairs1 occurs while state of affairs2 occurs
•	state of affairs has occurrence
The compound verb phrases using “starts” and “ends” that are already defined for “occurrence” could be added for states of affairs, but they are less important because they can be constructed. E.g., “John starts to eat before Mary comes home” can be formulated “(that (that John eats) starts) occurs before (that Mary comes home)”.
Also following verb concepts should be provided in support of tense/aspect for states of affairs:
•	state of affairs occurred
synonymous form: state of affairs happened
•	state of affairs has occurred
synonymous form: state of affairs has happened
•	state of affairs is occurring
synonymous form: state of affairs is happening
•	state of affairs will occur
synonymous form: state of affairs will happen
The compound cases of tense/ aspect, such as “will have …” are covered using the verb concepts listed above with nesting.  E.g., “John will have eaten” can be formulated as “that (that (John eats) has occurred) will occur”.  If compound forms are to be defined within the Date-Time specification, they should be defined by nesting the others.
The wordings for the four tense/aspect verb concepts above differ from wordings of similar verb concepts in the Date-Time specification for occurrences. This is deliberate in order to capture the intent of past, present perfect, present continuous and future as they occur in natural language.  For example, a phrase like “is in the past” might be seen as appropriate about an occurrence that has already happened (since the time of an occurrence is intrinsic in its being an occurrence).  Timing need not be intrinsic in a state of affairs, so a state of affairs that has occurred and that will occur again would not be understood as “is in the past”.  It has occurred and it will occur.
Also, the Date-Time specification rightly defines “occurrence” as a specialization of SBVR’s ‘state of affairs’ by the way that it uses SBVR’s definition of ‘state of affairs’ within its definition of ‘occurrence’.  Therefore, ‘state of affairs’ should be clearly indicated as a more general concept of ‘occurrence’.

Source:
Don Baisley	[don.baisley@microsoft.com]
Donald Chapin	[Donald.Chapin@BusinessSemantics.com]
John Hall	[John.Hall@modelsystems.co.uk]
John Healy	[john_dh@mac.com]
Keri Anderson Healy	[keri_ah@mac.com]
Ron Ross	[rross@BRSolutions.com]
Stan Hendryx	[Stan@hendryxassoc.com]

The UML packages in the supporting UML document (bmi/2011-08-01.mdzip) are not consistently aligned with the sections of the specification.  In particular:
 Sections 8.1 and 8.2 of the specification are both in the TimeInfrastructure package, but section 8.3 is not.
 Section 8.3 of the specification matches the Situations package, except that 8.3.7 Schedules is in a separate Schedules package.  And the Situations package also contains the Tense concepts from 10.3.
 Sections 9.1 to 9.4 of the specification are all in the TimeScales package, but sections 9.5 and 9.6 are not.
 Section 9.5 of the specification matches the Calendars package, except that Gregorian calendar (9.5.5) is a separate UML package, and Internet Time (9.5.7) is a separate UML Package.
 Section 9.6 of the specification (Time Tables) is in the Schedules package, along with the Schedules concepts from 8.3.7.
 Section 10 of the specification matches the Indexicals package, except that Tense and Aspect (10.3) is in the UML Situations package.  (The UML model treats tense as a relationship of situations to time, but the time concepts involved are indexical.)
 Section 11 of the specification matches the DurationValues package, except that month values (11.6) and year values (11.5) are in the UML Gregorian calendar package.
 Section 12 of the specification matches the UML TimeCoordinates Package, except that Section 12.4 is in the Gregorian calendar package.
 Annex D of the specification matches the UML Packages: Sequences (D.1), Quantities (D.2), Mereology (D.4), except that D.3 Scales is included in the UML Quantities package.


In sum, some reorganization of the specification did not result in a consistent reorganization of the UML model.  In general, the UML packaging should be made consistent with the text.  But, if the Gregorian calendar package is intended to be separable, then Gregorian elements in other parts of the specification may need to be treated as exceptions.  In addition, one can argue that the 'time table' and 'schedule' concepts are closely related and should be together in the specification.


I do not recommend the use of nested UML Packages.  It complicates the UML model and all references to the UML concepts defined in it.

The Date/tTime UML model contains a package called "SBVR", which is a selective subset of SBVR concepts from the SBVR Meaning and Representation Vocabulary (MRV).  The specification itself does not identify that vocabulary as 'adopted' or 'included'.    If it is actually adopted into the Date/Time vocabularies, the Date/Time UML model should import the SBVR MRV MOF model and not include an ad hoc replacement.


The Date/Time UML model also uses a set of undefined stereotypes:  fact type, fact type role, etc.  These stereotypes appear in the diagrams in the specification.  The stereotypes use SBVR terms, but they are not defined in the SBVR v1.1 specification, nor are they defined anywhere else.  If nothing else, these should be defined in Clause 5.

The Date/Time Annex D "Fundamental Concepts" says that it is 'informative'.  But the declarations and definitions in Annex D are formally specified in SBVR and UML.  Moreover, the UML classes and associations defined in Annex D are used directly in the formal normative specifications in the body of Date/Time.  The 'quantities' model (D.3) is used in peripheral way in defining 'duration' and 'time unit', and might be considered informative only, since only some 'time units' are 'measurement units' (as defined in D.3).  But the part/whole relationship (D.4) is used normatively in clause 8, and the sequences (D.1) and scales (D.3) concepts are critical to the formulation of definitions and necessities in clause 8 and in clause 12.  So, it appears that Annex D.1, D.2 and D.4 are critical to the normative specification.


It is the stated intent of the Date/Time specification that the Annex D models are outside the scope of the Date/time specification, and are used only because no appropriate formal specification of these concepts has been found.  Thus a later specification with focused expertise in these areas can be expected to supplant these elements of the Date/Time specification at some future time.  Nonetheless, the text of the Date/Time specification, and its formal models, depend on Annex D being interpreted normatively until some future time when it is formally replaced by a specification with wider support. 
Recommendation:  Make Annex D 'normative', and retain the caveat that it is an interim specification.

Many of the UML classes defined in Clause 8 have several UML operations.
While it may be easy to guess the relationship between the operations and the associations, there is no text that defines these operations, or even mentions their relationship to the associations.  In each case, these operations should be formally documented under the "glossary entry" for the class.  (The description in clause 5.2 is helpful, but it alone does not meet the documentation requirement.  It just says that each such operation is somehow related to some defined association.)

In Clause 5.2, in explaining the conventions used for the UML models, the first two paragraphs contain the follwing text:


"The intent of the model is two-fold: (a) to illustrate this vocabulary with UML diagrams; (b) to satisfy the RFP requirement for a matching UML model.


The UML model is derived manually from the SBVR-based text in this document. In case of any discrepancies between the SBVR-based text in this document and the UML model, the text prevails because it is the original model."


This text suggests that the purpose of the UML model is illustrative, rather than normative, and that it is derived from, and inferior in status to, the SBVR model.  Bullet (b) belies the rest -- the RFP asked for a normative UML model.  This specification presents one, and that is what should be said here.  


The Date/Time Vocabulary is (mostly) presented as a formal SBVR "business vocabulary" using the text conventions of SBVR.  Clause 5.1 should say that, and does not.  The interpretation of the vocabulary presentation is more important than the use of SBVR Structured English as the pseudo-formal form for definitions.  It is the interpretation of the vocabulary structure that leads to the normative SBVR XML files attached to the specification.


The UML model is a normative representation of that part of the Date/Time Vocabulary that can be conveniently represented in UML.  The later text of 5.2 specifies the conventions used in creating the normative UML representation.  They differ in some ways from the conventions presented in SBVR clause 13.  That difference should be expressly stated in 5.2.  The differences are primarily related to enabling effective formal specification of definitions and necessities in OCL.


The SBVR business vocabulary includes normative elements that are not represented in the UML model, typically because UML does not support Synonyms and Synonymous forms.  That is the extent of the inferiority of the UML model.  Any other discrepancy between the two models is an inconsistency in the specification.


SBVR SE is not a standard language and SBVR Annex C provides neither a grammar nor a formal interpretation for it.  Formally, it is just a style that clarifies the use of English text.  The formal forms of the Date/Time definitions and necessities are (incompletely) provided as OCL (and CLIF) formulations, that is, in standard languages with standard formal interpretations.  Any discrepancy between the perceived meaning of the SBVR SE formulation and the OCL formulation may be an inconsistency in the specification, or just a misreading of the SBVR SE, but in any case the OCL formulation should take precedence -- it is well-defined.

The Date-Time Vocabulary (DTV) document FTF beta 1 draft Mike sent on Dec. 8, 2011 shows a concept of 'time unit' specialized as:
- 'precise time unit', a specialization of 'measurement unit'
- 'nominal time unit'


It is understood that in DTV, a 'precise time unit' is a kind of ISO 80000 measurement unit (i.e., 3.8 in ISO-80000-1):


real scalar quantity, defined and adopted by convention, with which any other quantity of the same kind can
be compared to express the ratio of the second quantity to the first one as a number


The DTV names for 'time unit' and 'nominal time unit' are misleading because in the Dec. 2011 DTV FTF 1 beta document,
these terms are not defined as kinds of ISO 80000 measurement units. 


From the DTV FTF perspective, the objection against defining 'time unit' and 'nominal time unit' as ISO 80000 measurement units is that 'month', 
a kind of 'nominal time unit', varies between 28 and 31 days and therefore does not exactly fit the definition of measurement unit per ISO 80000.
In pure ISO 80000 terms, this would suggest that 'month' would be a measurement unit with a variable conversion factor from 'day', which is defined as a normative measurement unit in ISO 80000-3, item 3-7.d.


I believe that the DTV interpretation of ISO 80000 measurement unit is too restrictive and should be changed such that a DTV 'time unit' is in fact a kind of ISO 80000 'measurement unit'.


There is compelling evidence to support this change in ISO 80000 itself:


1) The definition of year as a non-SI measurement unit in ISO 80000-3, Annex C, item 3-7 shows an example where the conversion factor is variable:


a := 365d or 366d


One tropical year is the duration between two
successive passages of the Sun through the mean
vernal equinox.

This duration is related to the corresponding difference
in mean longitude of the Sun, which depends on time in
a not exactly linear form; i.e. the tropical year is not
constant but decreases at a rate of nearly per
century. The tropical year is approximately equal to 
365,242 20 d ≈ 31 556 926 s.


2) The value of a quantity can be expressed in three ways according to ISO 80000-1, item 3.19:
- a product of a number and a measurement unit
- a number and a reference to a measurement procedure
- a number and a reference material


3) 'month' could be defined as an ISO 80000 'conventional reference scale', that is, a quantity-value scale defined by formal agreement.


This could facilitate defining that 'month' is a 'conventional reference scale' varying between 28 and 31 'days'.
Specializations of 'month' could be made for 28-days months, 29-days months, 30 days months, 31 days months where such specializations can be defined as ISO 80000 derived units of 'days' with a precise conversion factor.


4) 'amount of substance', one of the 7 base quantities in the International System of Quantities, ISQ, is intrinsically context-dependent:
See the remarks in ISO-80000-9, 9-1:


Amount of substance of a pure
sample is that quantity that can
often be determined by
measuring its mass and
dividing by the molar mass of
the sample.

Amount of substance is
defined to be proportional to
the number of specified
elementary entities in a
sample, the proportionality
constant being a universal
constant which is the same for
all samples.

The name “number of moles�
is often used for “amount of
substance�, but this is
deprecated because the name
of a quantity should be
distinguished from the name of
the unit.

In the name “amount of
substance�, the words “of
substance� could, for
simplicity, be replaced by
words to specify the substance
concerned in any particular
application, so that one may,
for example, talk of “amount of
hydrogen chloride, HCl�, or
“amount of benzene, C6H6�.
It is important to always give a
precise specification of the
entity involved (as emphasized
in the second sentence of the
definition of the mole); this
should preferably be done by
giving the molecular chemical
formula of the material
involved.


Just like 'amount of hydrogen chloride' is a specialization of 'amount of substance',
'January' is a specialization of 'month.
All are measurement units in the sense of ISO 80000.


The DTV specification should clearly indicate the correspondence between the DTV vocabulary and the corresponding ISO 80000 vocabulary.
These correspondences are important to clarify the relationship between the use of ISO 80000 vocabulary in DTV and SysML's QUDV.

Many Date Time Vocabulary concepts have very formal definitions that are hard for one of the target audiences – business users – to understand.  For example, the definition of the Allen Relationship 'time interval1 is properly before time interval2' reads:
Definition:	the time interval1 is before the time interval2 and the time interval1 is before a time interval3 and the time interval3 is before the time interval2

This formal definition provides a precise meaning for use by reasoning engines, but it takes even an expert human awhile to understand.  Business users have little chance of understanding it.  

The solution proposed by this Issue is that this and every other Date Time Vocabulary concept should have an informal definition or description that explains the concept to the business user audience.  Note that SBVR permits a concept to have multiple definitions, so adding informal definitions need not displace any existing formal definitions.

The Date Time Vocabulary provides verb concepts that relate the time order of any two time intervals (e.g. 'time interval1 is before time interval2'), any two situation models ('situation model1 precedes situation model2'), and any two occurrences ('occurrence1 precedes occurrence2').  Another common ordering relationship is among three time intervals, situation models, or occurrences, as in 'time interval1 is between time interval2 and time interval3', 'situation model1 is between situation model2 and situation model3', and 'occurrence1 is between occurrence2 and occurrence3'.  These ternary verb concepts should be added to the Date Time Vocabulary.

In clause 9.5.3, 'calendar day' is defined as:  'time point that is defined by a given calendar and during which approximately one revolution of the earth occurs on its axis'. Clause 9.3 defines 'time point' as 'scale point that is in a time scale and that specializes the concept 'time interval'. Fortunately, 9.3 also says 'time point' is a concept type, so the idea of specialization makes sense.  That is, the definition in 9.3 means: a time point is a scale point on a time scale, and a time point is a concept that specializes 'time interval'.  A concept that specializes time interval is not a time interval during which the earth rotates -- its instances are.


Recommendation:


In clause 9.5.3, change the definition of calendar day to 'time point that is defined by a given calendar and that corresponds to time intervals during which approximately one revolution of the earth on its axis occurs'.
In clause 9.3 reword the definition of time point to 'concept that specializes the concept time interval and that is a scale point on a time scale.  

The definitions of the weekdays in 9.5.6 simply identify them as 'day of week' time points.  ('day of week' is erroneously represented as a name instead of a noun concept)  What is being defined in the textDTV  is apparently the individual time point, but the UML diagram shows that each day of week time point is in fact a general concept (that corresponds to time intervals).  The text should make this clear.


Further, the delimiting property for each of these concepts is specified in a Necessity that is intended to be taken as part of the definition: e.g., Each Tuesday is met by a Monday.  That is, the intended definition of the general concept 'Tuesday' is: time interval that is an instance of a calendar day and that is met by an instance of Monday.  The definition of the individual concept "Tuesday" is: the time point that has index 2 in the week of days scale, and that is the concept 'Tuesday'.  Somehow the text has to make these two definitions clear.  
It takes significant effort for the reader to understand that the individual 'Tuesday the time point' can have instances, so that "each Tuesday" makes sense.  It may be sufficient to phrase the Necessity as:  
Each instance of (time point) Tuesday is met by an instance of (time point) Monday.  (SBVR Annex C provides a notation [Tuesday] to refer to the concept as a thing, and CLIF has no problem with the designation (symbol+concept) playing both predicate and argument roles.)


Finally, the following Necessity should appear under 'calendar day' in 9.5.3:
For each calendar, each instance of a 'calendar day' that is defined by the calendar is met by at most one instance of a calendar day that is defined by the calendar. Otherwise, the ontology could technically permit a day to be both a Tuesday and a Friday.  It may be that this follows from the necessities for the relationships of the time scales to the Time Axis.  If so, the Necessity is not needed, but a Note should mention the sequencing rules.

On p.82, in the middle of section 9.3, the UML diagram that is Figure 9-5 is about the concepts that are in section 9.4, and the UML diagram that is Figure 9-7 (in section 9.4) depicts the concepts on p.82.


I don't know whether to file this as an official issue or not.  We can fix this if we have to change the diagrams anyway.

At the end of section 9.3 the fact type 'finite time scale subdivides time point' is defined and depicted in Figure 9-6.  This fact type is a commonly used property of finite time scales, and is not specific to individual time points.  That is, the finite time scale day-of-hours subdivides every day-of-month, for example.  So the text and diagram should be at the end of 9.2, where finite time scale is defined.  


Also, diagram 9-6 does not show the operations on time point and finite time scale that are associated with this fact type and shown in diagram 12-12.


Finally, diagram 12-12 (section 12.4) shows this fact type as well, but section 12.4 never uses it, and diagram 12-12 shows a <<specialization>> relationship that is never discussed anywhere in the text.  If the relationship is important, it should be discussed.  Otherwise, the subdivision association is out of place in diagram 12-12 and the "specialization" dependency should be deleted from the UML model.


Recommendation:


Move the diagram and text for 'finite time scale subdivides time point' to the end of 9.2, include the operations on the diagram.  Delete the fact type from diagram 12-12, and delete the "specialization" dependency altogether.

The description for "Properly overlaps" in this section is as follows:


"The ‘properly overlaps’ relation distinguishes the case in which there is a part of each time interval that is not a part the other from all the cases in which one time interval is entirely a part of the other. The general ‘overlaps’ relation subsumes all of them. ‘Properly overlaps’ describes the first time interval as starting and ending earlier than the second, whereas ‘is properly overlapped by’ describes the first time interval as starting and ending later."


Problem:


In the phrase "‘Properly overlaps’ describes the first time interval as starting and ending earlier than the second," the sense which is intended is in fact "‘Properly overlaps’ describes the first time interval as starting earlier than the second starts and ending earlier than the second ends"


That is, a word was left implied in this phrase, but no one word would, when inserted here, have carried the correct meaning. For example "starting and ending earlier than the second [starts]" would be incorrect, as would "starting and ending earlier than the second [ends]". So when the reader parses this surface-level syntax and inserts any implied words for a deeper level cognitive representation of the meaning, any such representation would be incorrect compared to the intended sense of this term. 


Similarly in the phrase which follows: 
"... whereas ‘is properly overlapped by’ describes the first time interval as starting and ending later."


 should then (presumably) be:
"... whereas ‘is properly overlapped by’ describes the first time interval as starting later than the second starts, and ending later than the second ends."


Proposed Solution:
Rewrite the offending paragraph as follows:

"The ‘properly overlaps’ relation distinguishes the case in which there is a part of each time interval that is not a part the other from all the cases in which one time interval is entirely a part of the other. The general ‘overlaps’ relation subsumes all of them. ‘Properly overlaps’ describes the first time interval as starting earlier than the second starts and ending earlier than the second ends, whereas ‘is properly overlapped by’ describes the first time interval as starting later than the second starts, and ending later than the second ends."

In clause 8.2.3 (p.54), the first corollary to axiom D.4 is stated in mathematical English:
If t1 and t2 are time intervals such that t1 starts t2, then D(t1 starts t2 complementing t3) = D(t2) ­
D(t1).
But "t1 starts t2 complementing t3" is a proposition, which does not have a duration. The intent is:
If t1, t2 and t3 are time intervals such that t1 starts t2 complementing t3, then D(t3) = D(t2) ­ D(t1).


There is a further requirement, namely that time interval t2 is "finite" (which does not seem to be a concept in clause 8). 'Time interval has particular duration' cannot always be satisfied. So it appears that the term 'finite time interval' must be defined: A time interval that has a duration.


The CLIF formulation of this corollary is also incorrect. It should read:
(forall ((t1 "time interval") (t2 "time interval") (t3 "time interval"))
(if
(and
(exists ((d duration))
("time interval has duration" t2 d)
("time interval1 starts time interval2 complementing
time interval3" t1 t2 t3))
(= ("duration of" t3)
(- ("duration of" t2) ("duration of" t1))) ))


If the concept 'finite time interval' is added, then this can be simplified:
(forall ((t1 "finite time interval") (t2 "finite time interval")
(t3 "finite time interval"))
(if
("time interval1 starts time interval2 complementing
time interval3" t1 t2 t3)
(= ("duration of" t3)
(- ("duration of" t2) ("duration of" t1))) ))


The second Corollary has the same problem. It reads:
If t1 and t2 are time intervals such that t1 finishes t2, then D(t1 finishes t2 complementing t3) = D(t2) ­
D(t1).
It should read:
If t1, t2 and t3 are time intervals such that t1 finishes t2 complementing t3, then D(t3) = D(t2) ­ D(t1).


The CLIF formulation of the second corollary is also incorrect. It should read:
(forall ((t1 "finite time interval") (t2 "finite time interval")
(t3 "finite time interval"))
(if
("time interval1 finishes time interval2 complementing
time interval3" t1 t2 t3)
(= ("duration of" t3)
(- ("duration of" t2) ("duration of" t1))) ))


In both cases, the existence of time interval t3 is the subject of a different axiom. So it suffices to say, for any three time intervals that are related in a certain way, their durations are related in a certain way.


The remaining issue is that Clause 8.2 does not define the CLIF function for the SBVR attributive construct 'duration of'. Axiom D.2 suddenly introduces the notation "duration of" as a function. The intent is that the fact type 'time interval has duration' introduces both a CLIF predicate "time interval has duration" AND a CLIF function, which can be defined axiomatically as:
(forall ((t "finite time interval") (d duration))
(iff ("time interval has duration" t d)
(= ("duration of" t) d) ))
This declaration should be added to the entry for the fact type that introduces the "attributive role" 'duration'.


Note also that construction of a CLIF function from an SBVR attributive role pattern only behaves as expected when the role is played by a unique thing for each possible value of the function argument. If it is possible that the role is empty or multivalued for a valid argument, the CLIF function would have to be described as returning a set. So this construct does not follow some general pattern. It must be appropriately declared in each case. In this case, the supporting axiom:
Necessity: Each time interval has at most one particular duration.
should be stated, and then the above function axiom completes the model.

A time interval that starts at a definite time (be it "now", or "starting when 13 states have signed the declaration", or "starting when the exchange offers our stock on the floor", and continues without end is a different kind of "forever" than the time period specified in 9.4.


Similarly, there are intervals that start at indefinite time in the past and end at a stated time ("now" or whatever).  Such intervals are referred to in phrases such as "Until the Wildlife Protection Act goes into effect in 2016", where no event marks the start of the interval in question - only its end.
These are cases in which
a) a time period has a first time point but no last time point, or
b) a time period has a last time point but no first time point.


Unlike 'forever', which is unique, those categories of time period have infinitely many instances.  And unlike time periods that have a start time and an end time, or a start time and a duration, the DTV does not provide a simple fact type for specifying them: the time interval 'after (time point)' or 'from (time point) on', and the time interval 'until (time point)'.


Some such fact types would clearly be useful in a business vocabulary.

In clause 9.4, 'forever' is defined as: "the time period that does not 
start on some time point and does not end on some time point".  This is 
interpreted "there are two time points t1 and t2 such that the time 
period does not start on t1 and does not end on t2".  What is intended 
is "the time period that starts on no time point and that ends on no 
time point".  Further, this definition does not identify any time point 
sequence that makes the term 'time period' appropriate, and it 
eliminates all described ways to define a time point sequence.  It seems 
that 'forever' should be classified 'time interval', with the above 
qualifications, not 'time period'.  Or perhaps the intent is:  "the time 
period that is the instance of each time point sequence that has no 
first time point and that has no last time point".

Also, some Note should clarify the relationship of 'forever' to the Time 
Axis.  Clause 8.1 does not say that the Time Axis is a time interval.  
Is 'forever' the time interval that is the "segment of the Time Axis" 
that covers all of it?  Or is 'forever' the same thing as the Time 
Axis?  I.e., is the Time Axis itself a time interval and 'forever' a 
synonym?

The UML model included in the beta-1 specification contains a number of Magic Draw extensions. The extensions make the file unreadable by any but the Magic Draw tool. An OMG machine-readable file should be vendor-independent.

The DTV UML model uses various stereotypes that are document in clause 5.2. These should be "documented" in a UML profile.

Also, SBVR changed the primary term for "fact type" to "verb concept" and for "fact type role" to "verb concept role".  The stereotypes and the description in 5.1 should be updated to match.

Specification: Date Time Vocabulary
Version: beta-1
Title: inaccurate formulation of definitions in CLIF
Source: Michael Gruninger <gruninger@mie.utoronto.ca>


Summary:
In the OMG Date Time Vocabulary, all of the axioms use relativized quantifiers,
even for defined relations. For example,


(forall ((t1 "time interval") (t2 "time interval"))
      (iff    ("time interval1 equals time interval2" t1 t2)
              (and    ("time interval1 is part of time interval2" t1 t2)
                      ("time interval1 is part of time interval2" t2 t1))))


This sentence is equivalent to


(forall (t1 t2)
   (if (and ("time interval" t1) ("time interval" t2))
      (iff    ("time interval1 equals time interval2" t1 t2)
              (and    ("time interval1 is part of time interval2" t1 t2)
                      ("time interval1 is part of time interval2" t2 t1))))


It seems to me that what is really wanted is
(forall (t1 t2)
      (iff    ("time interval1 equals time interval2" t1 t2)
              (and    ("time interval" t1) ("time interval" t2)
                      ("time interval1 is part of time interval2" t1 t2)
                      ("time interval1 is part of time interval2" t2 t1))))


Recommendation:
For all of the predicates that are type-specific, change all the definitions to use simple quantifiers and make the typing of the arguments part of the equivalent condition.  This would also eliminate the need for many uses of relativized quantifiers in other Date Time Vocabulary axioms.

Clause 12.4 contains the following: 
 "The concept “time point converts to time period on time scale” enables conversion of a time point on some time scale1, to a time period on the given time scale. The target time scale always is finer, meaning that it has a granularity that is less than or equal to the granularity of time scale1. This means that time point is equivalent to a time period on time scale2. 
 "For example, the Gregorian month that is indicated by “January” (on the Gregorian year of months scale) is the time period from Gregorian day of year 1 through Gregorian day of year 31 on the Gregorian year of days scale."

In all of this text, the term 'time period' should probably be replaced by 'time point sequence'.

Clause 12.4 then contains this entry:

"time point converts to time period on time scale
"Definition:  time point converts to a time point sequence on the time scale and the time period
instantiates the time point sequence"

The verb concept 'time point converts to time point sequence' appears in diagram 12-12, but is not defined anywhere, and 'time point converts to time period on time scale' does not appear on the diagram.  So the obvious interpretation is that 'time period' should be replaced by 'time point sequence' in the verb concept entry.  But then the definition is circular.

In DTV Clause 9.5.2, all the time-of-day time point definitions are similar. For example, it defines 'hour of day' as: time point that is on the day of hours scale and that is identified by the number of elapsed full hours since midnight on a given calendar day


But each 'hour of day' is a category of time intervals.  The time point is "identified by" its index.  The "number of elapsed full hours" is how the index and the time point relate to the corresponding time intervals.  The definition should read something more like:
_time point_ that is on the _day of hours_ scale and that /corresponds to/ each _time interval_ that has duration 1 hour and that starts a calendar day, if the index of the time point is 0, or that has duration 1 hour and that is met by a time interval that starts a calendar day and that has duration n hours, where n is the index of the time point and is not 0.

The other definitions should be similar.  Similarly, 'midnight' appears to be the time point that corresponds to each time interval that has duration 1 second and that starts a calendar day.  It is nominally an event that occurs exactly 12 hours before a reference "noon" -- a zenith of the sun.

This spec should provide a simple library of datatypes for use in UML and data modeling. This is present in many physical data standards (e.g. SQL/JDBC, XML Schema) but is lacking in OMG for platform independent modeling. That would include types such as:

-          Date

-          DateTime

-          TimeStamp

-          Duration

Section 8.1.1 of the Date Time Vocabulary specifies a minimal mereology for time intervals, but fails to address the question of whether there are any "atoms" -- time intervals that contain no other time intervals.  
If there could be atomic time intervals, then the axioms in section 8.1 are insufficient to prove some of the "corollaries".  It appears that the intent of 8.1 requires an axiom that is not stated:  There is no smallest time interval.  For each time interval t, there is a time interval that is a proper part of t.


Also, it is not clear from 8.1.3 that any time interval must have a proper part that starts it, or a proper part that finishes it.  A proper part need not have a complement, and no axiom asserts that "time interval1 is properly during time interval2" implies the existence of "complementary" time intervals that start and end time interval2.  It only implies the existence of two disjoint proper parts

Specification:  Date Time Vocabulary
Version:  beta-1
Title:  Quantity Kind is a categorization type
Source:  Ed Barkmeyer, NIST, edbark@nist.gov (as directed by the FTF)


Summary:


Section D.3.1 of the Date Time Vocabulary declares the concept 'quantity type' as follows:
 Definition: categorization type for ‘quantity’ that characterizes quantities as being mutually comparable
 Concept Type: concept type
Figure D.5 shows 'quantity kind' as a <<concept type>>


It appears that the SBVR tag Concept Type should have the value 'categorization type', to match the definition.  Moreover, the UML <<concept type>> stereotype does not carry the more important "powertype" semantics that typifies a categorization type.  The UML diagram should show 'quantity kind' as a powertype or categorization type.  Making it a powertype should also result in a formal UML specification that its instances classify 'quantity'.

DTV section 12.3.4 defines 'calendar date' as: "Gregorian year month date coordinate or Gregorian day of year coordinate or year weekday coordinate".  
This is clearly a definition of 'Gregorian calendar date' or 'Gregorian date'.  The general concept 'calendar date' is "absolute time coordinate that indicates a time point that corresponds to exactly one calendar day".  The list given in the definition is just the ones defined for Gregorian calendars.  The general concept 'calendar date' is useful, and the term should not be assigned to Gregorian dates only.  As defined, a 'date time' (date and time) also requires a Gregorian date, but it is not clear that there is a useful generalization.


Recommendation:  Rename 'calendar date' to 'Gregorian date' or something the like, and define the general concept 'calendar date' as well.

In clause 12.1.2, Figure 12.3 shows an association 'atomic time coordinate has index', but no such verb concept is declared in the text.  (The verb concept, however, is used in numerous definitions.)
In clause 12.3.1, the UML diagram refers to a 'G. month of year coordinate', which is not documented in the text, and it says the 'G. day of year coordinate' is compound, but it is defined in the text to be atomic.

It is not clear what list the text bullets following the diagram in 12.3.1 are members of, and they are not sentences.  Further, they have the pattern:  "Gregorian year coordinate composed of a Gregorian year, for example 2010", but coordinates are defined to 'indicate' time points.  They are not "composed of" time points in any sense.  On the other hand, a 'G. year month coordinate' is composed of two time coordinates, but not two time points.


The definition of 'Gregorian year coordinate' is: "absolute atomic time coordinate that indicates a Gregorian year that has the index equal to the index of the Gregorian year coordinate".  The term 'Gregorian year coordinate' is being used in its own definition.  The definition should read:  "absolute atomic time coordinate that indicates a Gregorian year".  (There are no other time coordinates that indicate Gregorian year time points.)  There is a related Necessity: Each Gregorian year coordinate indicates the Gregorian year that has an index that is equal to the index of the Gregorian year coordinate.  This pattern also applies to G. day of month, G. day of year coordinates, and hour, minute, second coordinates.  It applies to numeric 'Gregorian month coordinates', but the time coordinate "January" does not have an index, per se.  "January" is a term for the time point, but not an index (integer).  The UML model (Figure 12.3) makes 'atomic time coordinate has index' a derived relationship, but that is false, given the intent:  the index of the time coordinate is used to identify the time point, not taken from the identified time point.  And in that case, the non-derived 'index' property is 0..1.



The definition of 'Gregorian year month coordinate' misuses the verb concept 'compound time coordinate combines atomic time coordinate':  "Definition: absolute compound time coordinate that combines the set of {a Gregorian year coordinate, a Gregorian month coordinate} and indicates the Gregorian month that..." A 'set' is not an 'atomic time coordinate' and cannot play that role.  What is intended is:  
"Definition: absolute compound time coordinate that combines a Gregorian year coordinate and that combines a Gregorian month coordinate and that indicates a Gregorian month."  That is sufficiently delimiting.  The structural rule that determines which month it indicates can be stated as a separate Necessity.  This "combines the set of" pattern is used in every compound time coordinate definition in 12.3.


Note also that the formal statement of these definitions/necessities suffers from the lack of a basic arithmetic vocabulary (in Annex D?).  Elsewhere DTV just says the arithmetic expressions are described in English or mathematical notations.  If the arithmetic expressions are removed from the definitions, it becomes easier to do that.  The mathematical formulations can be stated in CLIF and OCL.

Figure 12.1 shows 'time coordinate' as a specialization of SBVR 'representation', which is said to be the relationship between an expression and the meaning it denotes.  No UML diagram shows 'time expression' (from 12.1.2), which one would expect to be the corresponding specialization of 'expression'.


In 12.1, the definition of 'time coordinate' is: "representation of a time point by an atomic time coordinate or compound time coordinate that indicates the time point".  This is both circular and incorrect.  A time coordinate cannot represent a time point by a subtype of itself, it must represent a time point by an expression.  The definition should read: "representation of a time point by a time expression" (to exclude representation by a definite description).


One would expect a 'time expression' to be "the expression of a time coordinate" (from SBVR 'representation has expression', mislabeled 'expression uses representation' in the diagram), but it isn't.  It is said to be an expression involving an index (integer) and a time scale, which means it is not the expression of a compound time coordinate.


In 12.1.2, the definition of 'atomic time coordinate indicates time point' requires the time expression to contain an index, which means that the "February" example is invalid.  The expression (string) "February" includes neither an index nor a time scale.  The time coordinate, as a 'representation', is the association of "February" with the time point that is month of year 2.  The atomic time coordinate thus acquires the time scale and index properties from the time point it indicates.  But the expression "February" does not have those properties.  "February" is associated with that time point via 'concept has designation'.  If DTV is to explain how a time expression is associated with a time point, it has to distinguish the properties of the expression from the properties of the association (that SBVR calls a 'representation').


A 'simple time expression' is either the expression of an 'index', which would be some expression of an integer, OR a 'signifier' for a time point (from SBVR 'concept has designation' and 'designation has signifier (expression)').  The signifier could be a given name, like "March", or a constructed term involving the scale and the index, like "Gregorian month 3".  (What 12.1.2 describes is only the last case.)
A 'compound time expression' is some syntax that combines two or more simple time expressions.


In SBVR style, then, an atomic time coordinate is a time coordinate whose expression is a simple time expression, and a compound time coordinate is a time coordinate whose expression is a compound time expression.


And the rules for determining what a simple time expression indicates, i.e., how the link that is the atomic time coordinate is constructed, depend on the nature of the time expression.  In particular, the context of a compound time expression may make the intent of an index expression clear, as in "3/31/2012", where the "3" is only recognized as a month of year index because of its placement.

The definition of ‘calendar date’ is wrong. It reads ‘Gregorian year month date coordinate or Gregorian day of year coordinate or year weekday coordinate’.  A calendar date should indicate a specific time interval, but a Gregorian day of year coordinate does not. It appears that the definition confuses ‘Gregorian day of year coordinate’ with ‘Gregorian year day coordinate’.

Recommendation: change the definition to mention ‘Gregorian year day coordinate’ rather than ‘Gregorian day of year coordinate’. Clarify the intent of ‘calendar date’ by adding “General Concept: absolute time coordinate”, and by adding a Description such as “A calendar date indicates a specific time interval of duration ‘day’.”

The glossary entry for Time Axis has a ‘General Concept:’ entry that reads “mathematical representation of the succession in time of instantaneous events along a unique axis”.  The caption is wrong; it should be a ‘Definition:’.

Specification:  Date Time Vocabulary
Version:  Beta-1
Title:  A calendar day is not a time period
Source:  Ed Barkmeyer, NIST, edbark@nist.gov


Summary:


DTV section 9.5.3 defines 'calendar day', 'calendar month' and 'calendar year' to be time points, as shown in figure 9.10.
The entry for 'day period', however, contains a Note that reads: "Calendar day is a period that starts and ends as defined by a calendar. Day period starts and ends at any time within a calendar day."
And there are similar notes under 'month period' and 'year period'.


A calendar day is not a '(time) period'; it is a 'time point'.  But a 'day period' time interval can indeed start and end at any time point "within", i.e., on some time scale that subdivides, a calendar day.


The Note could be modified to read:  "A calendar day corresponds to time intervals that start and end as defined by a calendar."  Or, the concept "calendar day period" could be introduced to refer to time intervals that instantiate calendar days.  The juxtposition of the two otherwise unrelated sets of concepts in Figure 9.10 suggests that the latter may be what was intended.  And in any case, the repair must be applied to year period and month period as well.


It appears that a 'day period' is not just a time interval whose duration is one day, because of leap seconds.  A note to that effect would be valuable.  (It is clear that months and years are of variable duration.)

D&T makes a subtle but very important between Duration and DurationValue.


Consider adding a note in 8.2 to alert the reader about this important distinction:


A Duration can be specified by choosing a particular Duration Value as the expression of that Duration. (See Duration Value in …)

Summary: 
These two ‘year of weeks scale’ and ‘year of weekdays scale’ are defined using the ‘time scale subdivides time point’ verb concept.  That verb concept assumes that the start of the time point coincides with the start of the scale, but this is not true for these two scales because calendar weeks are not coherent with calendar years.  A special verb concept needs to be used to relate weeks and weekdays to calendar years.

The Date Time Vocabulary needs to be able to support statements about periods of time which extend indefinitely into the future, and also describe periods of time which will have begun at indeterminate times in the past. As an example of the former, it is possible and meaningful for a contract to make statements about commitments or rights which extend in perpetuity, such as “Perpetual Bonds” which are bonds that pay interest forever. 


In general, it is necessary to be able to make meaningful statements which embody the concept of “Forever”. Similarly, it  is necessary to be able to make meaningful statements which have been going on in perpetuity up to the present time.


The DTV specification does currently allow for making statements about infinite time going forward, but not about time periods which have started at some indefinite time in the past. Meanwhile there are three other issues in play which touch on this same area. These may have an impact on the current ability to make statements about infinite time into the future as well, depending on their final resolution.


The issues which have a bearing or potential bearing on this matter are: 


-       Issue 16992: “Corollaries to Axiom D.4 in 8.2.3 are misstated”;
-       Issue 16993: “no syntax for indefinite time periods (date-time-ftf)”;
-       Issue 16997: “forever is misdefined”


In summary, the requirement that needs to be met with the resolution of this and the above-referenced issues is: 


-       Extend ‘forever’ with two new concepts:
1.      Indeterminate time in the past
2.      Indefinite time in the future


-       Ensure that the concept “forever” can be adequately defined (per 16997) including with reference to the time axis;
-       That there is syntax for the specification of indeterminate time periods that began at some point in the past and last up until the present (per 16993)
-       That the restatement of the axiom and corollaries referenced in 16992 take account of the two concepts above (indeterminate time in the past and indefinite time in the future)

Each kind of time point is a ‘concept type’.  That is, the instances of each kind of time point are themselves concepts.

The specification is inconsistent about this.  Referring to the beta 2 document:

Figure 10.2 shows the following as <<concept type>> but the text does not:
calendar day
calendar week
calendar month
calendar year
Figure 11.1 and the associated text do not mark these concepts as ‘concept type’, but should:
Gregorian day
Gregorian week
Gregorian month
Gregorian year
Figure 11.3 and the associated text do not mark these concepts as ‘concept type’, but should:
common year
leap year
centennial year
quadricentennial year
Gregorian day of year
Gregorian day of month
Gregorian month of year
Figure 11.7 shows the following concepts that should be marked <<concept type>>
Gregorian year
Gregorian day
Figure 12.1 and the associated text do not mark these concepts as ‘concept type’, but should:
calendar week
week of year
day of week
weekday of year
Figure 13.1 and the associated text do not mark these concepts as ‘concept type’, but should:
hour of day
minute of day
second of day
leap second
minute of hour
second of minute
Figure 13.3 shows the following concepts that should be marked <<concept type>>
hour of day
minute of day
Figure 14.1 shows the following class ‘internet time point’ that should be marked <<concept type>>, but that is missing from the text

Clause 11.8 in the beta-2 specification claims to enable comparison of ‘Gregorian months’ with ‘Gregorian days of year’.  These time point kinds are not comparable because one is on an infinite time scale and the other is on a finite time scale.  In fact, this section should be referring to ‘Gregorian month of year’

In clause 8.6 of the beta-2 specification, the verb concepts ‘time point1 through time point2 specifies time interval’ and ‘time point1 to time point2 specifies time interval’ do not work for the example ‘10pm to 2am’.  Reason: the Definitions of these verb concepts form a time point sequence over the time between the two time points, but for this example, the time point sequence “wraps around’ the end of the day of hours scale.  And no time point sequence can do that.

The UML diagram Figure 13.1 shows leap second as a subclass of second-of-day.
The text in 13.2 defines it to be an instance of second of day, and the definition of day-of-seconds confirms this.  The UML diagram is incorrect.  


'leap second' may be an intercalary time point that arises from a change in time offset, rather than a second-of-day.

The definition of 'calendar' in clause 10.1 relies upon SBVR's 'conceptual schema'.  However:
1.	'conceptual schema' is not included in the list of adopted SBVR concepts in clause 4.
2.	SBVR 1.1 moved 'conceptual schema' to clause 10.1.2.1, which means this concept is part of the semantic and logical foundation of SBVR, but not actually in any of the SBVR vocabularies.

Annex D.2.1 includes a verb concept 'next sequence position succeeds sequence position' that references a concept 'next sequence position' that is not defined anywhere

There are two glossary entries for the concept 'time span', one in clause 16.4 and one in clause 17.2.  The two glossary entries are not identical, nor do they define coextensive concepts.

Clause 16 is titled "Situations", and there is no text that describes the scope of the section.  But subclause 16.1 is titled 'Temporal Concepts for Situations', which is the intended scope, and is followed by a description of the scope.  Further, clause 16.1 has a single subclause, which defines only the situations concepts.


It appears that Clause 16 should be titled 'Temporal Concepts for Situations', the current heading "16.1 Temporal Concepts for Situations" should be deleted, thus placing the subsequent paragraphs at the head of Clause 16, and subclause 16.1.1 should be numbered 16.1 with its current title.

The UML diagram in Figure 13.1 shows 'leap second' as a subtype of 'second of day'.
The Definition of 'leap second' in clause 13.2 defines it to be an instance of 'second of day'.
The text is correct.  The UML diagram should show that it is an instance, like 'midnight'.

Title:	‘Time of Day’ misused
Source: Mark Linehan, IBM, mlinehan@us.ibm.com

Summary:
The term ‘time of day’ is a synonym for ‘time of day coordinate’ in clause 12.1, but is used in the sense of a time point in several places in clauses 9.5.4 and 9.5.6

The glossary entry for ‘local time’ in clause 9.5.4 refers to a non-existent term ‘standard time of day’.

In support of the addition of a very generic concept for all kinds of occurrences to SBVR at the DTV RTF’s request, so that all specifications that define a particular kind of occurrence based on this generic SBVR concept, the Date-Time Vocabulary needs entries to do this.
Resolution:
1.	Adopt ‘occurrence‘ from SBVR as specialize it as ‘temporal occurrence’.
2.	Adopt ‘what-happens state of affairs has occurrence’ from SBVR as specialize it as ‘what-happens state of affairs has temporal occurrence’.

Revised Text:
In clause 16 immediately before the entry for ‘situation model', INSERT two new entries:
temporal occurrence 
Definition:	occurrence that occurs for a given time interval



… add whatever contraints are required by DTV on ‘temporal occurrence’, which is adopted from SBVR …



Necessity:	A state of affairs will have occurred for a time interval if and only if the state of affairs has an occurrence and the occurrence interval of the occurrence is the time interval.

Necessity:	A state of affairs has been actual if and only if an occurrence of the state of affairs is in the past.
Necessity:	A state of affairs is actual if and only if an occurrence of the state of affairs is current.
Necessity:	A state of affairs will be actual if and only if an occurrence of the state of affairs  is in the future.

Necessity:	An occurrence has been actual if and only if the occurrence is in the past.
Necessity:	An occurrence is actual if and only if the occurrence is current.
Necessity:	An occurrence will be actual if and only if the occurrence is in the future.
what-happens state of affairs 


… add whatever contraints are required by DTV on ‘what-happens state of affairs’, which is adopted from SBVR …


what-happens state of affairs has temporal occurrence 
Definition:	’ what-happens state of affairs has occurrence’ that includes only temporal occurrences 


… add whatever contraints are required by DTV between ‘temporal occurrence’ and ‘what-happens state of affairs’, which are adopted from SBVR …



In clause 16.7, in the entry for ' situation model occurs now', ADD a Nole:
Note:	The statement “the state of affairs has an occurrence that is current” is semantically equivalent  to the SBVR characterisitc “state of affairs is actual”.

In clause 15.1 page 154 DTV defines 'time interval is current' as:
"time interval that includes a time interval1 that is past and that includes a time interval2 that is not past"


That definition is ambiguous and the most likely parse is nonsense. The problem is that 'and that includes' might be parsed to refer to time interval1, which is not what was intended.  The intent is
"time interval that includes both a time interval that is in the past and a time interval that is not past". I believe SBVR SE might support this latter formulation (perhaps without the 'both'). 

The definitions of the indexical time intervals in clause 15 include references to time point concepts that either do not exist or are not visible in the included vocabularies.  These concepts include:

day of year (which does not exist)
hour of day (in clause 13, which is not included in clause 15)
minute of hour (in clause 13, which is not included in clause 15)
calendar week (in clause 12, which is not included in clause 15)
week period (in clause 12, which is not included in clause 15)

Recommendation: define 'day of year' in clause 10.2, and move the other concepts from their current locations to clause 10.2.

In the beta-2 document, clause 10.8 defines a verb concept 'time point converts to time point sequence on time scale'.  A typical use is 'Gregorian month converts to time point sequence on the Gregorian days scale', which is given as a specialization.  The 'time scale' role is redundant in the main verb concept, and the use of individual concepts in the derived verb concepts is poor practice.

Clause 10.8 defines the verb concept 'time point1 shares common time scale with time point2'.  This verb concept is then specialized with verb concepts such as 'Gregorian year shares the Gregorian days scale with Gregorian month'.  These specialized verb concepts are defining 'ground facts', and probably should be given as Necessities rather than verb concepts.

Title: Clause 8.3.2 dependency upon clause 10.2
Source: Mark H. Linehan, IBM Research, mlinehan@us.ibm.com
Summary:
The definitions of several standard time units that are defined in clause 8.3.2 are dependent upon "period" concepts that are defined in clause 10.2.  Specifically:

The Definition of day in 8.3.2 references calendar day, which is in 10.2
The Definition of year in 8.3.2 references calendar year, in 10.2
The Definition of month in 8.3.2 references calendar month, in 10.2
The Definition of week in 8.3.2 references calendar week, in 10.2

This violates the Vocabulary structure shown in figure 7.3

Source: Mark H. Linehan, IBM Research, mlinehan@us.ibm.com
Summary:
The verb concept 'time interval1 precedes time interval2', defined in clause 8.1.4, appears to have the same semantics as 'time interval1 is before time interval2' in clause 8.1.2.  Also, figure 8.5 fails to show 'time interval1 precedes time interval2'.

In DTV Beta-2,Clause 8.2.3, there are two verb concepts:
 time interval1 is duration before time interval2
 time interval1 is duration after time interval2


From the alternative form: "duration before/after time interval2", it seems clear that the intent of these verb concepts is to allow a time interval to be defined by a reference time interval and a duration, e.g., the two weeks before the jump-off date, the day after the meeting (day).  Each of these denotes exactly one time interval.


But the Definitions mean that the verb concepts simply state the duration between two time intervals. This may be useful when the intent is to state the duration between two events, but it is not the meaning of 'duration before time interval', and it cannot be used to define a time interval.  Either these verb concepts should be defined to be the ones intended by the alternative forms, or the alternative forms should be separate verb concepts.

Issue 17426 added a verb concept 'atomic time coordinate has index' to clause 10.5.3 for consistency with figure 10.10.  Issue 17428 redefined 'atomic time coordinate', and deleted this concept from the figure but failed to delete 'atomic time coordinate has index' because it was not in the convenience document of the time.

Recommendation: delete 'atomic time coordinate has index'.

Issue 17129 added a new Annex I titled "UML Profile for SBVR".  The title is misleading; this is a profile for SBVR as used in the Date-Time Vocabulary, not a profile for SBVR in general.

Recommendation: change the title of this Annex and related text to make clear this profile documents the stereotypes used in the UML model of the Date-Time Vocabulary. The profile does not address all of SBVR and is not intended for use beyond DTV.