A look at the use of timestamps in our databases and applications. What pitfalls may be encountered? Why do we need timezone support? Timestamps are an important datatype in DB2. We now have timezone support as well as expanded precision. We'll look at how the timezones work and how we can use them

1 2 First, some basics.

On DB2 for z/OS the preferred method of displaying dates and times use ISO representations. These are the external string formats that are used when interacting with the data. The internal representation uses a packed format without sign information. Each component is packed separately.

This is different than system time fields that tend to be very large integers. Other DBMS implementations may also use integer formats internally. The character format should be the same though, providing a good measure of compatibility.

3 Timestamps combine the Date and Time formats into a larger single datatype that includes optional fractions of seconds and a time zone.

Internally, again, the timestamp consists of its individual components in a packed format.

4 DB2 for LUW uses the same internal format, but we don’t have time zone support (yet).

5 The external string format is used for interaction with most host languages because most of them don’t have special datatypes for dates, times, or timestamps. The external string format includes punctuation and the actual arrangement of the date/time elements is depending on your system/localization settings.

For a very long time, those of us using DB2 for z/OS have seen the ISO date format seen here. ISO updated the format and DB2 defines this as the JIS format. This lets our existing applications run the same as they have always run.

6 Java has built-in support for timestamps, but it does not have time zone support. DB2 provides the DBTimestamp datatype for Java that does.

7 JavaScript also has a Timestamp datatype. What it doesn’t have is a Date. So, when we retrieve Date fields from DB2 the application layers need to convert each date into a timestamp. Here is a common error when that conversion is done. - The value of ‘00:00:00’ is added to the end of the date field to derive the new timestamp. - The timestamp is send to a JavaScript layer running in a person’s browser. - The time is truncated when formatting the date for display (because we started with a Date datatype and the user only wants to see the date) - In some cases, the user observes the date field is off by a full day. - The user just happened to be in a time zone west of the data center, so when the timestamp was localize (in the JavaScript) the hour became “earlier” and the date rolled to the prior date. Not the desired result.

The quick fix: Use ‘12:00:00’ for the time when deriving a timestamp from a date.

8 Why? We could just use UTC, but most people don’t think that way and we’ve gotten used to them. The whole idea of time zones and UTC came about to standardize observed times so that we can adapt when we travel.

9 The time zone, despite the fact that we call each by a distinct name, is actually an offset of UTC. This offset is added to UTC to get our local time and subtracted from our local time to derive UTC.

Time zones are often under the control of political entities. People living in nearby areas tend to want to use the same time. So, there are no straight lines for determining what zone you are in, you need a map of some sort.

10 Regardless of time zones, we also have some inconsistencies with time itself. We use the rotation of the planet and its orbit around the sun to adjust both the calendar and time of day.

Calendars are adjusted by adding days every few years. This compensates for the astronomical year being about 6 hours longer than we think of it as being. If we didn’t compensate, the seasons would migrate across the calendar over time.

Similar to leap years, we use leap seconds to adjust for the time of day versus the earth’s rotation. Maybe we could have changed the length of a second to compensate, but then the earth doesn’t rotate at a constant rate.

Prior leap seconds have been added to the time, creating an additional second in some days. It is possible that some future adjustment would remove a second, making that day just a bit shorter.

11 Daylight Savings Time and its impact on us and our databases is somewhat more than making it difficult to get up in the morning. DST was started to increase the number of evening daylight hours.

The shift to DST where we add an hour to the clock is generally a safe time for applications. But the shift back can be a problem. DB2 handles it just fine, but does your application?

Many think of DST as a one hour shift forward/backward, but this isn’t always the case. The amount of adjustment, like time zones, is controlled by political entities. That means the adjustment could be 2 hours and 30 minutes. Also, because the southern hemisphere experiences seasons that are opposite from the northern side, locations there can be shifting in the opposite direction from us.

12 How does DST impact our applications? As we design our databases, we often need a way to provide a unique key. Timestamps, conceptually, provide a linear value that we tend to think of as unique. This makes it something worth considering. But time doesn’t always go forward and (as we’ve already seen) it doesn’t flow consistently. Shifts to/from DST cause us to jump in time and we need to account for that (unless you have the luxury of taking down the application every time there is a jump backward).

Time zones in our timestamps can help with this issue. Because the time zone is stored with the timestamp, it reflects the DST switch as well as the local time.

Another impact of DST is how it impacts the ability to adjust time for a time zone. Without knowing the actual date you cannot tell whether a time in Chicago should use CST or CDT.

13 Here is an example of what could happen in a diary database. If we omit the time zone from the database, it looks like someone was arrested. If we keep them (and re-order the results above accordingly) then we can see a much better outcome.

14 In DB2 for z/OS, we can manage our time zones implicitly and explicitly. Our application default settings (in DSNHDECP) provide an outer layer of default. Within our programs, we can use special registers for more direct control.

The SESSION TIME ZONE and CURRENT TIME ZONE special registers work differently. Notice the datatypes and what they contain.

These are used when we have TIMESTAMP WITH TIMEZONE datatypes and our literals/variables don’t specify an offset. Each variable/column can contain its own time zone that may be different from the others.

15 Now, lets jump back to the discussion of time In computers, we see time as a periodic series of interruptions. Those increment the clock. Unfortunately, physics gets involved too. The interrupts do not occur with consistent intervals, some gaps between the interrupts may be longer or shorter depending on the temperature of the chips in the computer as well as other environmental conditions. The clock only increases in duration internally, but drifts forward and backward in accuracy compared to external time.

When we want to know the current time, we have to ask the system to tell us. The time we get back has a lot of dependencies on the system, programming language, local settings, and other considerations. We can have an alleged accuracy down to the nanosecond (or sometimes even smaller) or get back time in full seconds only.

16 Because each individual computer may be keeping its own time based on its own conditions, we need to bring them closer together to correct for drift. Various protocols have been developed over the years to do this.

On the Internet, we have NTP that was developed to try and adjust time based on the settings of a remote connection to another computer. Those time- keeping computers are set up to use more accurate sources to keep them closer to observed time. On our computers, a local service wakes up periodically and checks the time at the server. The local clock is adjusted accordingly. This adjustment can be large or small and forward or backward. How it is adjusted is system dependent.

On the mainframe, we have the need to keep the clocks closer in sync than we do in distributed environments. Without consistent time-keeping we’d have serious problems in a parallel sysplex configuration.

17 One of the other more recent capabilities DB2 has provided is more granular control over the precision of fractional seconds in our timestamp columns. We can now save some space if we don’t need microseconds (the default) or use a more precise value to keep up with the faster CPUs in our systems.

The use of precision is separate from the use of time zones.

18 Working with timestamps in Java can cause you to lose precision if you aren’t careful.

19 To maintain high precision timestamp information, using the DB2-supplied DBTimestamp datatype is worth strong consideration.

Assuming, of course, that you really care what time it is.

20 John Maenpaa has been working with DB2 since 1986. He has real experience working with DB2 as a programmer, database administrator, system administrator and system programmer. He has worked for several large corporations on the implementation and support of large high performance databases, and developed z/OS configurations used for secure execution of high-performance Internet applications. He works extensively with DB2 on z/OS, AIX, Linux, and Windows platforms.

21