A point in time field supports a business need for an information system to know when an event took place (or will take place). Date, Time, and Date/Time field values represent a quantity of time involving a specific unit of measure and precision. Like other quantity values, they can participate in calculations (E.g. subtracting one date from another to determine the number of days in-between).
NOTE: This article is Part 9 of Information System Data Fundamentals For Business Analysts. See Part 1 – Series Introduction for links to other articles in the series, plus definitions of the terms Information System, Record, and Field within the context of this series.
Time Scales
The most common time scale used by organizations for date and date/time fields is the Gregorian calendar, with origin point 2000-ish years ago. That said, Microsoft Excel offers to display date values based a number of other calendars, many of which are religion-based.
Fields involving time typically assume midnight as their origin point. Organizations that operate in more than one time zone must take into consideration the difference between the local time an event takes place and Coordinated Universal Time (UTC).
NOTE: The time zone applicable for a given area is dictated by the country the area is in. The whole country can be in a single zone, or specific country-defined regions (e.g. states, provinces) can fall within a designated zone. Time of year-specific adjustments for daylight savings time (DST) can also be by country or country-defined region.
Event-based Records and Fields
There are records such as PURCHASE, FLIGHT, and JOURNAL ENTRY, that represent events of interest within an information system. These records act as the context for one or more point-in-time fields and other event-specific information. For example, FLIGHT records having a Scheduled Departure Date/Time and Scheduled Arrival Date/Time field along with Departure Airport, Arrival Airport fields.
There are records such as CUSTOMER, PRODUCT, and LOCATION which are not events themselves, but can be the context for events of interest. E.g. CUSTOMER Date Of Birth, PRODUCT Launch Date, LOCATION Effective Date.
NOTE: The unit of measure for a given point-in-time field may be defined globally within the information system, specific for a given record or field, or record instance-specific - identified by a separate field. (See Part 7 – Quantity Fields)
Precision
Different organizations or industries can have different precision needs for the same event. For example, a person’s birth. Day is the most common precision for a Date Of Birth field for a CUSTOMER or STAFF MEMBER. However, organizations that deal with official birth records record the event precision is minute. A precision of year is all that’s needed for an AUTHOR was Born in information systems supporting publisher, book retailer, and library organizations. E.g. Steven King - 1947.
If the point-in-time field involves precision finer than day, the options progress from hour, to minute, to second, and finally some number of decimal places of seconds. Minute precision is usually sufficient for human-related activities. When greater precision is needed, microchip-based timekeeping devices are utilized to source a value. For example, a POS terminal recording the PURCHASE Date/Time to the nearest thousandth of a second.
NOTE: There can be business needs for a time precision to be a specific incremental precision value. A common example is for an APPOINTMENT where the value for a Start Time is limited to quarter hour increments (e.g. 0, 15, 30, and 45 minutes within a given hour of the day). For such time points, the explicit set of precision increments should be defined as part of the detailed needs for the point in time field.
Event Time Period
Some business event-related needs involve the concept of a time period. Records can represent a time period in the following ways:
- Begin and End Point In Time Fields
- Begin or End Point In Time Field plus a Duration Field
- Contiguous Begin or End Point In Time Fields.
Begin and End Point In Time Fields — Two different point-in-time fields are defined within a record context, both with the same units of measure and precision. The field names and/or definitions should make clear the field’s role as being either the start or end of the period. Business rules need to be confirmed indicating if two or more periods are allowed to overlap, and if gaps in time are allowed between periods. E.g. POSITION ASSIGNMENT Begin Date and End Date – business rules need to be clear regarding allowable assignment period overlap.
Begin or End Point In Time Field Plus a Duration Fields — Given either a start or end point in time, plus a duration, the other time point can be derived. For example, given CONTRACT Start Date and Duration fields a value for the field CONTRACT End Date can be derived.
Contiguous Begin or End Point In Time Fields — In cases where time period events are contiguous (i.e. no event overlapping and no gaps), only a begin or end time point field is needed within the context of a record. Because no time gaps are allowed, the time point value in the next record instance indicates the end of the period of the prior record instance. For example, CURRENCY EXCHANGE RATE Effective Date/Time. At the point in time a new rate value becomes effective – captured in the information system as a new record instance, the previous value ceases to be in effect. Whether to define the start point and assume the end point or the reverse depends on which best represents the business event. In the exchange rate example, there being a new rate taking effect would be of primary interest.
NOTE: part of defining the details of an event time period is ensuring whether a boundary field’s value is intended to be included or excluded in the period. For example - a period defined to end at midnight – does the business expect a record with that exact value to be included or excluded in the period?
Next Article – Part 10 – Record Navigation Fields
Author: Dan Tasker
Dan is the author of over 30 requirements-related articles and other resources. His 45+ year career in Information Technology has involved organizations in a variety of industry sectors in the United States, Canada, Australia, and New Zealand. His business analysis experience includes projects involving in-house software development, software vendor solution development, and COTS software acquisition and implementation. He continues to be passionate about quality requirements and helping business analysts produce them. He can be contacted at [email protected].