Editorial Rss

Wrapping Up Time

Today I want to wrap up this series on time with a short review and some thoughts on the virtual nature of time.. 

Time based events may be a single event. That single event may be a durable event with continuing implications, such as a wedding date. You get married at one time’ but, you continue to be married until some other event changes that state.
It may be a single event with no continuing result. You catch a foul ball at a baseball game. You caught the ball, and that’s the end of it. No continuing action.

An Event can be represented as a period. That period always has a start date. It may have an end date. The end date may not yet be determined. I like to call a period of time a Time Segment.

Some types of Events are often compared to other events. Time segments may be compared with other time segments, or points in time. Points in time may also be compared with points in time.

Many natural Time segments have a rolling nature. Hours, Days, Quarters, Years, Decades, etc. all have a rolling property each time they change. They represent the fact that time never stops. For this reason, it is difficult to identify an event with some of the non-specific rolling concepts of time. 

We often compare business performance for the current time segment with a previous time segment. Common segments are month, quarter and year. Sales, unemployment, construction permits issued; these are all reported frequently based on the current month compared to the previous month. But, the current month is a virtual, moving value that changes each time a new month begins. These are the more difficult time dimensions on which we report.

Some databases will create a table of time segments with all of these periods pre-calculated. A time table is then created relating all of the different time segments for all of the possible permutation supported by the system. Then, when a entity having events adds a record, it is related to the time table, so all periods become available. This method is most often seen in a data warehouse, where new time segments are calculated daily as part of the daily updates. 
Other systems calculate the time segments for every report. 

For any event, there is always an international factor involved. GMT may be used to compare dates across time zones. Some prefer UTC (Coordinated Universal Time) as a more accurate measurement. UTC does not support those time zones using Daylight Savings time. Storing an event as UTC with the offset for the time zone where the event occurs, allows you to report across time zones in a consistent fashion.

Why not share some of your favorite time structures? Leave a comment, or drop an email to