DATABASES Handling Time Zones and Day- light Savings Time Changes in Sybase ASE Databases By Mark Gearhart, SAP

You probably think this is an old sub- I am often in contact with clients in ject, laid to rest many years ago. Well I UTC -4, +1, +8, +3, and -5 (i.e. New York, thought so too, until I discovered several London, Hong Kong, Moscow, and Hous- bugs in the handling of time throughout the ton), although it varies with the projects I’m application I’ve encountered during several working on at any given time. Daylight sav- recent assignments. The fact is, there is little ings time only adds to the fun. information and very few solutions for han- Luckily there are many tools around to dling time zones and daylight savings times help me keep on top of things, such as the within applications in general, not just for free World Clock Meeting Planner. And be- my particular applications. cause I’m old-fashioned at heart, I find old- Everything related to time has always school works well for me too: been an engineer’s nightmare. From the adoption of Gregorian calendar in 1582 to international calendars and Universal Time Coordinated (UTC), dates and times have, within recent history, moved to the unstable world of geopolitics. No doubt this trend will continue and even accelerate. Since time-related data is a standard requirement for many applications, engineers are faced with the challenge of resolving numerous time-related issues, with the daylight sav- ings time (DST) problem being the most difficult one to solve. Company sites often provide time tables for their global employees. This article describes a 100% relational database and SQL solution which gives da- I don’t feel too bad about this, because tabase applications the ability to translate even the most important corporate people between UTC time and the moving target have issues with time and space. If they exhibited by local time for any of the 393 didn’t, then why would they construct tre- time zones [5] of the world. With this so- mendous monuments to world time at their lution, we solve problems dealing with the offices? storage and display of data across 23 and 25 hour days, and we handle the translation of time between local time zones for both Mark Gearhart isis aa systemsSenior Consultantengineer geopolitical boundaries on land and longi- withat Deutsche SAP. He Bank, is involved were he in is theinvolved devel- tudinal boundaries at sea. This solution can opmentwith the ofdevelopment database architecturesof derivative and be customized for any desired effect, and ex- richsynthetic internet equity applications trading systems. for temporal He ceeds programmatic solutions implemented andis certified realtime in systems.both SAP His ASE background and SAP in other languages and subsequently adapt- encompassesHANA, with athe particular energy andinterest financial in da- ed for database applications. industriestabase performace with a special and HANAinterest analyt in data- storageical capabilities. architectures He andalso fast uses user SAP inter IQ- Juggling Time Zones faces.and SAP He Powerdesignercan be reached quiteat mark.gear regularly- [email protected] developing data warehouses. He Juggling time zones is a skill many can be reached at mark.gearhart@ globally-thinking professionals find them- Here is the view as you walk into one of db.com. selves perfecting these days. the major Wall Street investment banks.

1 Time Translation Being human, I still suffer from an occasional twinge of TZD, As you can see, time zones do not obey the physical laws which or Dementia. If you’re in the same boat, or just think would state that local can be determined for any- you could do with some ideas on how to better manage your time where in the world by adding 1 hour for each 15 degrees of lon- and the time of your database applications, then just ask yourself, gitude counted in an easterly direction from one’s meridian, or by what time is it really? In fact, what do you really need to think about subtracting 1 hour for each 15 degrees counted in the westerly di- when designing applications which must think about time? rection. If it were only that simple. Some countries have made things particularly difficult. Take What time is it really? for example. Australia has both horizontal and vertical Nowadays, what time it is really depends more on the lawyers, time zones in the summer. Queensland and the Northern Territory economists and much less on the astronomers, geographers, and do not observe DST, however, the middle of Australia (Northern scientists like in the 19th century and before. To modularly think Territory and South Australia) use half an hour offset from nearby about this, here is an example of the chronological adoption [1] of Western Australia and the eastern states of Australia. Additionally, different “Standard Times” in Singapore over the years: the Northern Territory does not use DST and South Australia does. In this instance, for example, Nullabor and Darwin, located in rela- Period in use Time offset from UTC Name of Time tively same longitude in the middle of Australia have the same time Until 1905-05-31 +6hr 55m 25s Singapore Mean Time during local winter (1 hour and 30 minutes ahead of Perth time, 1905-06-01 - 1932-12-31 +7hr 00m 00s Standard Time Zone Western Australia). However, during local summer, Nullabor and 1933-01-01 - 1941-08-31 +7hr 20m 00s Daylight Savings Time Darwin maintain a 1 hour difference. Darwin is 30 minutes ahead 1941-09-01 - 1942-02-15 +7hr 30m 00s Daylight Savings Time of Perth (use DST as of December 3rd, 2006) time and Nullabor is 1 1942-02-16 - 1954-09-12 +9hr 00m 00s Tokyo Standard Time hour 30 minutes ahead of Perth time (Western Australia - use DST 1945-09-13 - 1981-12-31 +7hr 30m 00s DST/MST/SST as of December 3rd, 2006). Topping it off, Australia DST works by 1982-01-01 - Present +8hr 00m 00s Singapore Standard Time moving the clock back in the spring and forward in the fall rather than the other way around like the northern hemisphere, which Figure 1. Standard Time in Singapore. most likely has something to do with having winter in July and summer in December. Got it?

SYDNEY Seconds before and a er time change forward 12 11 1 Daylight Savings Time 10 2 starts April 1st, 2012 Local UTC Time 9 3 Time DST Oset Zone 12:59:59 +1h UTC+11h EDT LONDON 8 4 1:00:00 -> 2:00:00 No UTC+10h EST Seconds before and a er time change forward 7 5 6 2:00:01 No UTC+10h EST 12 11 1 Daylight Savings Time 2 starts March 25th, 2012 10 Seconds before and a er time change backwards Local UTC Time 12 9 3 Time DST Oset Zone 11 1 Daylight Savings Time 12:59:59 No UTC GMT 2 starts October 7th, 2012 NEW YORK 8 4 10 1:00:00 -> 2:00:00 +1h UTC+1h BST Local UTC Time Seconds before and a er time change forward 7 5 6 2:00:01 +1h UTC+1h BST 9 3 Time DST Oset Zone 12 11 1 Daylight Savings Time 8 4 1:59:59 No UTC+10h EST 2 starts March 11th, 2012 2:00:00 -> 1:00:00 +1h UTC+11h EDT 10 Seconds before and a er time change backwards 7 5 Local UTC Time 6 1:00:01 +1h UTC+11h EDT 12 9 3 Time DST Oset Zone 11 1 Daylight Savings Time 8 4 1:59:59 No UTC-5h EST 10 2 starts October 28th, 2012 7 5 2:00:00 -> 3:00:00 +1h UTC-4h EDT Local UTC Time 6 3:00:01 +1h UTC-4h EDT 9 3 Time DST Oset Zone 8 4 1:59:59 +1h UTC+1h BST 2:00:00 -> 1:00:00 No UTC GMT Seconds before and a er time change backwards 7 5 6 1:00:01 No UTC GMT 12 11 1 Daylight Savings Time 10 2 starts November 4th, 2012 Local UTC Time 9 3 Time DST Oset Zone 8 4 1:59:59 +1h UTC-4h EDT 7 5 2:00:00 -> 1:00:00 No UTC-5h EST 6 1:00:01 No UTC-5h EST

Figure 2. adjustments vary widely throughout the world based on location and time of year.

2 Time Translatoin Daylight savings time really complicates everything. For all or For the second case, we would preserve the time and time zone part of the year, some countries advance their time by one hour, as communicated by someone. For example a customer in London thereby using more daylight hours each day. In the case of advance- might be talking to support in Singapore for a Service hosted in ment, an hour is added in the spring (or fall), thereby skipping an New York. The support person would communicate with the cus- hour and producing a 23-hour day. Then in the fall (or spring) an tomer relative to his time zone: “You reported a service error to- hour is subtracted, which repeats an hour and produces a 25-hour day at 9:30 AM and yesterday at 9:15 AM”. We could deduce the day. There are also cases throughout the world in which daylight customer’s time zone from his location - but perhaps he normally savings times may adjust by more than one hour. In Israel, for ex- works from Frankfurt instead of London. A conversation a few ample, an adjustment of two hours is performed in the spring and weeks later reminding him of the problem he reported as “the 11:15 fall. AM incident” would be utterly confusing. Not all countries use a set day of the week to change to DST. If you choose to store a flag with your local time, denoting There are countries that use a set date for scheduling the transi- the zone of origin, then you must also flag time in other zones and tions. Moreover, not everyone adheres to the Gregorian calendar devise date arithmetic solutions. For example, if your flight leaves when it comes to scheduling DST changes, and consequently, time Frankfurt at 4 PM Frankfurt time and arrives in New York at 7 PM zone rules which are employed solely in the Gregorian Calendar New York Time, did it really take just 3 hours to fly across half of system need a new rule every year, even if the “native” rules remain and the entire Atlantic ? Local time arithmetic must unchanged. Furthermore, there are countries where DST transition reference some common point in time, otherwise you cannot com- dates are debated, negotiated, and agreed upon every year. There pute elapsed time. So, local time is not a very good base for doing can be several offset transitions during the twelve-month period. time arithmetic. Some countries can have offset transitions that have nothing to do If you do not normalize your data to UTC, you constantly have with DST. For instance, in 1946 Hawaii decided to change its stan- to keep track of the date, time and the time zone it is recorded in. dard time offset from -10.5 hours to -10 hours, which wasn’t a DST Bugs due to improperly processing local daylight savings times offset at all. To make things even worse, changes to “the rules” can tend to be particularly obnoxious as developers can easily overlook be made any time of the year. them or, not properly understanding daylight savings time, insist To entirely eliminate confusion about time, several countries their buggy code is correct. Sometimes these bugs may lurk inside have done away with time zones and daylight savings time com- a program for years before causing problems. Bugs showing times pletely. A country like China, for example, spans five meridians and that are an hour off tend to be easy to find. Bugs silently miscalcu- yet references just one time zone, which is UTC+8. Consequently, lating times that result in bad calculations may present no clue to your typical sunrise workday in western China begins at around 11 what caused the failure. AM. This may seem odd, but on the other hand if you want to call The choice of which time zone to run under is unfortunately your friend five meridians to the east in Beijing, you both can pick often based on where the company’s application is headquartered at up the phone at 11 AM. This makes it quite simple to think about the time the data server was first created, which usually works well time. for small companies that don’t have operations in other time zones. However, headquarters are sometimes moved, and small compa- How do we implement this? nies can grow to become global companies. Establishing a company We can start by thinking about UTC time. Let’s assume we standard early, which states that the server must run under UTC have an application residing in New York which must show times and all clients are responsible to translating from UTC to local time localized for clients in New York, London, and Singapore. If we had can save a great deal of trouble in the future. It is therefore wise to started with the idea of storing time according to the originator’s keep all time data in the database in UTC time, and additionally time zone, which is New York, this would intuitively lead to adding run the data servers in UTC time. This has several advantages: a “flag” to the timestamp in order to interpret that the time in either 1. The times in the database can be compared. For example, the London or New York or Singapore time zone. Experience sug- when a user in New York enters a time for a conference gests that this is a bad idea. with a colleague in Singapore, he types 2012-03-30 09:00 There are basically two distinct kind of requirements when EDT. The application convert this to UTC time and stores working with time zones: 2012-03-30 13:00 UTC in the database. On the other side of the world, the user in Singapore checks the time of the 1. Normalize to a common time - preferably UTC. meeting. The application reads the time from the database. 2. Keep the original time and time zone information. It still represents 2012-03-30 13:00 UTC, but based on For the first case, consider a scenario where we want to create Singapore’s time zone, the time is returned as 2012-03-30 visibility of the whereabouts of a mailed parcel on a global trip. It 21:00 SGT. Knowing that time is stored as UTC turns the can be perfectly acceptable to register each event in UTC and show entire problem into a simple calculation which lets another it to users in their own local time by applying the time zone and user in Frankfurt join the call at 2012-03-30 15:00 CEST. DST rules in effect for the particular location. 2. Using Java, you don’t have to do any conversions when reading or writing to the database because java.util.Date

3 Time Translatoin returns UTC time. You can obtain the current time using UTC time xntpd time new Date() or System.out.currentTimeMillis(). Also, since 1997-06-30 23:59:59.7 867715199.7 the database server is in UTC time, SQL datetime functions 1997-06-30 23:59:59.8 867715199.8 likewise don’t need conversions. In Sybase, select getdate() 1997-06-30 23:59:59.9 867715199.9 returns UTC time if the server was started in UTC time, or 1997-06-30 23:59:60.0 867715200.0 select getutcdate() will return UTC time regardless. Like- wise, in Oracle, select SYSTIMESTAMP from dual returns 1997-06-30 23:59:60.1 867715200.1 UTC time provided the database was created with the DB- 1997-06-30 23:59:60.2 867715200.2 TIMEZONE set to UTC [12]. 1997-06-30 23:59:60.3 867715200.3 1997-06-30 23:59:60.4 867715200.4 3. UTC time represents the physical world, therefore time 1997-06-30 23:59:60.5 867715200.5 neither reverses nor does it skip as in the case of local time, which can have 23, 24, or 25 hours days. There are 1997-06-30 23:59:60.6 867715200.6 no daylight savings adjustments in the UTC definition and 1997-06-30 23:59:60.7 867715200.7 therefore data stored in UTC time guarantees uniqueness. 1997-06-30 23:59:60.8 867715200.8 In UTC time, there are always 24 hours in a day. For any 1997-06-30 23:59:60.9 867715200.9 location in the world the local time can be calculated by 1997-07-01 00:00:00.0 867715200.0 adding or subtracting a certain number of minutes, which 1997-07-01 00:00:00.1 867715200.1 may vary from one day to the next depending on the day- 1997-07-01 00:00:00.2 867715200.2 light savings time adjustment. Figure 3. UTC and time.

UTC, UT1, TAI, and problems Some UNIX vendors have fixed xntp despite the fact that the So what exactly is UTC time? Let’s start with TAI (Internation- POSIX standard defines the broken behavior as a requirement [6]. al Atomic Time). One second of TAI time is a constant duration Odds are that you will never run across a case in your database ap- defined by cesium radiation. There are exactly 86,400 TAI seconds plications where UTC time is repeated, but in an engineering sense, in every TAI day. TAI has been measured continuously since 1955 it would be useful to consider this. and is the foundation of all civil time standards [2]. UT1 time is a time determined by the rotation of the earth. One day on earth isn’t Here are the current database solutions exactly 86,400 seconds. Its closer to 86400.002, wobbling slightly Most databases have some support for working with date/time from day to day. UTC time, which places 00:00:00.000 at 00 lon- values, taking into account the existence of time zones and daylight gitude, running through Greenwich, England, was created by ad- savings time. Most support is focused on interpreting and showing justing TAI by the appropriate number of leap seconds. When the date/time in the time zone of the user or connection. The fact that difference between UT1 and UTC approaches a point which it will in a typical architecture, where database connections are shared be- exceed 0.9 seconds, a is introduced to bring UTC time tween application users, changing time zones per connection is not back into closer agreement with UT1. With the difference between a feasible approach. UTC and UT1 growing at the rate of two milliseconds per day, Oracle supports the TIMESTAMP WITH TIME ZONE and or 0.7 seconds per year, currently about one leap second every 18 TIMESTAMP WITH LOCAL TIME ZONE data types [11], which months must be inserted into UTC. take time zones into consideration. TIMESTAMP WITH TIME There really isn’t anything wrong here, until you get over to the ZONE includes a time zone offset in its literal value. This is the UNIX operating system. The UNIX localtime() time-display rou- same as the timestamp “flag” noted earlier. Internally, though, the tine doesn’t support leap seconds. In effect, it treats TAI as UTC. data is stored as UTC with an offset. Someone in Germany or New So UNIX time slips 1 second away from the correct time for every York will see the same date and time zone information in either of 18 months. Unfortunately, this causes a problem because xntpd, the these formats: program that synchronizes clocks using the Network Time Proto- col, will produce duplicate UTC times in UNIX. In Figure 3, watch 2012-03-15 09:54:00 US/Eastern how the xntpd time scale increases as a leap second occurs. Notice 2012-10-30 21:42:00 -4:00 the 23:59:60 in UTC. This is a leap second. It extends 1997-06-30 TIMESTAMP WITH LOCAL TIME ZONE includes an im- UTC to 86401 seconds plicit time zone offset in its value . The data stored in the database is The xntpd time scale repeats itself! It cannot reliably produce normalized to the database time zone, and the offset is not stored. distinct UTC times. The main difference is that the values are interpreted as being in the time zone of the connection (user), and retrieved values are con- You probably don’t think this can matter much, and you are verted to the session’s time zone. right except for the case when we insert data into the system on 1997-07-01 23:59:59 UTC and then again at 1997-07-01 00:00:00 In a 3-tiered architecture, these data types makes little sense UTC. The result will be two rows of data with exactly the same UTC since database connections are shared (pooled) between end users. timestamp.

4 Time Translatoin This type of solution can also make incorrect assumptions Time zones are also represented, and there are currently 393 about your intent. If you give Oracle an ambiguous time during a time zones globally. Here is the time zone information for Chicago: future fall back, Oracle will assume standard time. You can, how- Zone Name GMTOFF Rules Format [Until] ever, eliminate the ambiguity by supplying a TZD attribute. There- Zone America/Chicago -5:50:36 - LMT 1883 Nov 18 12:09:24 fore, you must manually convert data to UTC time when selecting, which means you must also know the time zone in effect at the time -6:00 US C%sT 1920 of storage. There are configuration items to flag this ambiguity as an -6:00 Chicago C%sT 1936 Mar 1 2:00 error, but you must be aware how such configuration settings might -5:00 - EST 1936 Nov 15 2:00 affect other applications. -6:00 Chicago C%sT 1942 Some databases do not support time zones or daylight savings -6:00 US C%sT 1946 time at all. In Sybase ASE, for example, the bigdatetime, datetime -6:00 Chicago C%sT 1967 and smalldatetime data types do not store time zone information -6:00 US C%sT and the products are entirely ignorant of the concepts of time zones Figure 5. TZ database rules for time zones. and daylight savings time [13]. Sybase Servers only recognize and store the date and time portions of the values provided by the op- In the TZ database, a time zone has a very precise meaning. erating system, which are based on the time zone configured at the It is an area, all or part of one country, in which the legal time has operating system level (typically though the TZ environment vari- been uniform since 1970. Daylight savings time may be observed, able setting in UNIX or the Date/Time function of the Windows but if so, every place in the time zone must advance and rewind Control Panel) for the script that started the data server. its clocks at the same time. The time zones of the TZ database have been given names according to the form “Area/Location”, e.g. For Sybase we need solve the local-time problem ourself. For “America/Detroit”, “Europe/Stockholm” in order to make them Oracle and others, we can find problems with their approach which more understandable to people. It was also decided to use English can be solved by considering the alternative implementation de- names or transliterated equivalents, and to leave out punctuation scribed below. marks and suffixes. The TZ database is amazing Areas are represented either by or by ocean. Then goes the location’s name, which is usually the largest city of the re- Unless you are into the design of temporal applications, you gion. The database originators rejected the idea of using country probably don’t know about the TZ database, also known as the Ol- names in this database on the assumption that they are vulnerable son or Zoneinfo database [5]. The TZ database is a fairly new inven- to geopolitical changes. Geopolitics is a sensible subject and if a cer- tion. Its origins only go back to 1986 [9], and its use in applications tain application contains outdated data about the country’s bound- only go back to 2002 for the Java Runtime Environment [10], with aries and time zones, then heated controversies can arise among other language implementations coming much more recently. the nations. Thus, the inventors of TZ database decided to use the This public-domain TZ database contains code and data that names of the largest cities because that they are less likely to be represent the history of local time for many representative loca- changed, regardless of political upheavals. tions around the globe. It is updated periodically to reflect changes made by political bodies and daylight savings rules. This database is Let’s create a relational version of the TZ database stored in plain-text format [14] and includes a to produce There are several public domain programs for extracting a a binary file. For plain-text rules, here is an example of the DST time zone from TZ database, but most are programmatic. These definitions for the United States since 1918: programmatic solutions, in the form of an API, take a date, then Rule Name From To In On At Save Letter apply the many different rules that determine which zone to use, Rule US 1918 1919 Mar lastSun 2:00 1:00 D and whether the zone is in daylight savings time or not. The result Rule US 1918 1919 Oct lastSun 2:00 0 S is usually a local time given a UTC time, or a UTC time given a Rule US 1942 only Feb 9 2:00 1:00 W (War) local time. Rule US 1945 only Aug 14 23:00u 1:00 P (Peace) This is a great record-level solution but is inadequate for set- Rule US 1945 only Sep 30 2:00 0 S level operations in databases. To provide full database functionality Rule US 1967 2006 Oct lastSun 2:00 0 S and query ability, tables are needed. For our database solution, we Rule US 1967 1973 Apr lastSun 2:00 1:00 D construct two static lookup tables (the solution described in the rest Rule US 1974 only Jan 6 2:00 1:00 D of this paper uses a Sybase SQL syntax [7], but could be adapted to other databases as desired): Rule US 1975 only Feb 23 2:00 1:00 D create table TimeZone ( Rule US 1976 1986 Apr lastSun 2:00 1:00 D TtZone smallint not null, Rule US 1987 2006 Apr Sun >= 1 2:00 1:00 D TtName varchar(50) not null) Rule US 2007 max Mar Sun >= 8 2:00 1:00 D create table TimeTran ( Rule US 2007 max Nov Sun >= 1 2:00 0 S TtZone smallint not null, Figure 4. TZ database rules for daylight savings time. TtUTCStart datetime not null,

5 Time Translatoin TtUTCStop datetime not null, and is most commonly used when displaying times on a TtDST char(1) not null, report. For example, in a case where 2 AM is repeated, and TtOffset smallint not null, TtZoneAbbr char(5) not null) you are reporting dates at a resolution of hour, minute, second or millisecond, you can use this attribute to note Figure 6. Database schema for TimeZone and TimeTran relations. the 2nd 2 AM values.

The TimeZone relation contains a list of time zones. There are 4. ZoneAbbr: The time zone abbreviation is a short form 393 zone names for the world; 40 for just the U.S. There are also of the time zone for the offset in effect for each entry in 43 zone names which are used to support older System V zones TimeTran. Abbreviations can be as short as 1-character to like EST5EDT and legacy names like GMT+10. The GMT zones as many as 5 characters [18]. 1-character zones are typical- are for the military standard [3], which represents time zones from ly military times; B for Bravo Time (UTC+2), C for Charlie UTC-12 to UTC+12. The various military locations of the world Time (UTC+3) and so on. An example of a 5-character currently observe offsets from UTC-11 to UTC+14, with some time zone would be WGST for Western Greenland Sum- fractional hours among them, so the military standard won’t meet mer Time (UTC-2). all needs. On the high seas, however, official time is the zone time There are several public-domain programs available for con- as determined by longitude, so the military standard is perfectly verting the TZ database into various programmable formats. I have suited. Most nations have adopted this rule [16]. The military stan- taken one of these programs [15] and modified it to produce a for- dard ignores DST, so to use it you have to make the mental adjust- mat compatible with the TimeZone and TimeTran schemas. The ment for DST yourself. For this reason, you would likely never use following is a sample of the data contained in each relation: a military standard in your banking application. TtZone TtName The TimeTran relation contains the offsets from UTC time for 0 Etc/UTC each time zone listed in the TimeZone relation. Unlike in the TZ 1 Europe/London source files, we don’t separate zones from rules for winter/sum- 2 /Hong_Kong mer transitions. Instead, our TimeTran relation has a row for every 3 Europe/Moscow resetting of the clocks. For the U.S., this gives us a relation with 2720 rows from the beginning of time (1970) through 2011; for the 4 America/New_York whole world, we have a relation with 19,250 rows through 2011. 5 America/Chicago The attributes of TimeTran are as follows: 6 America/Denver 7 America/Los_Angeles 1. UTCStart/UTCStop: UTCStart holds the point in time 8 Australia/Sydney that separates this row from the previous one, and UTC- Stop holds the point in time that separates this row from Figure 7. Data for TimeZone Relation. the next. Both are expressed as UTC times. If you thread all the times together, from one row to the next for a given Tt- TtZone Zone TtUTCStart TtUTCStop TtDST TtOffset Abbr time zone, the time span will be contiguous. Local times are ambiguous, or may not even exist at all, so represent- 4 2010-11-07 08:00:00.000 2011-03-13 06:59:59.999 “ “ -300 EST ing each span of time for a time zone as local time doesn’t 4 2011-03-13 07:00:00.000 2011-11-06 06:59:59.999 “ “ -240 EDT make much sense. 4 2011-11-06 07:00:00.000 2011-11-06 07:59:59.999 “2“ -300 EST 4 2011-11-06 08:00:00.000 2012-03-11 06:59:59.999 “ “ -300 EST 2. UTCOffset: This is the amount of time that must be added 4 2012-03-11 07:00:00.000 2012-11-04 06:59:59.999 “ “ -240 EDT to UTC to get the local time. Note that this value is nega- tive for most of the Western Hemisphere. That might be 4 2012-11-04 07:00:00.000 2012-11-04 07:59:59.999 “2“ -300 EST surprising, but it’s the ISO 8601 way to do it [16]. Note 4 2012-11-04 08:00:00.000 2013-03-10 06:59:59.999 “ “ -300 EST that, even if we decide to reverse the sign for our own pa- 4 2013-03-10 07:00:00.000 2013-11-03 06:59:59.999 “ “ -240 EDT rochial purposes, that still wouldn’t get rid of the need to 4 2013-11-03 07:00:00.000 2013-11-03 07:59:59.999 “2“ -300 EST support negative offsets, even in just the U.S., since some Figure 8. Data for TimeTran Relation. territories have Eastern-Hemisphere time zones. UTC Offset is given in minutes. We don’t want just a number of With this, the data engineer should appreciate the fact that hours anyway, since several places in the world have off- time zone information has been taken out of the realm of black-box sets from UTC that are not an integral number of hours. API programming and put into the database, to be used with all the Before the adoption of standard time, we would have other data in the database. The application developer should appre- needed a 1-second resolution to express the local mean ciate the fact that he is now free to modify time zone information solar time. Nowadays, we don’t need to consider this. as he sees fit. The time zone America/New York can be changed to USA Eastern to benefit other users in the . New 3. DST: This attribute is a tag that can be shown next to the entries can be added for historic and future data. For example, in local time, to signify whether the time is in the 2nd, 3rd, Sybase the following ranges define the minimums and maximums and so on repeated interval for a daylight savings time backwards adjustment. This attribute is entirely optional,

6 Time Translatoin when used as defaults. These dates can be added to the TimeTran As written, this query is not good because it requires us to relation so that SQL operations involving these dates will not fail. know when the day begins and ends in UTC time. Of course these times will change because, for America/New York, sometime we Data Type Minimum Maximum are 5 hours away from UTC-0 and sometimes we are 4 hours away. smalldatetime (precision = 1 minute) 01-Jan-1900 06-Jun-2079 So, let’s include a function that will convert from local time to UTC datetime (precision = 3 milliseconds) 01-Jan-1753 31-Dec-9999 time. bigdatetime (precision = six decimal places) 01-Jan-0001 31-Dec-9999 The loctoutc function takes the local time and DST indicator Figure 9. Minimum and maximum date defaults. as input and returns the corresponding UTC time as output. For The only drawback to modifying the TimeZone or TimeTran the spring daylight savings time interval in the U.S., we consider relations would be the need to re-apply changes when the data is the local 2 AM hour as being non-existent. Therefore if this hour is refreshed from the TZ database. passed in, the UTC time is returned as null. The utctoloc function is the reverse of loctoutc. It takes UTC Using the TimeTran and TimeZone relations time as input and returns the corresponding local time and DST indicator as output. UTC-to-local time translations are performed according to the interval and offset configured for the time in question. For the U.S. create function loctoutc(@loc datetme,@dst char(1),@TtZone smallint) returns datetime as Eastern time zone, time translation for the spring and fall daylight begin savings time intervals would proceed as follows: return (select dateadd(mi,-TtOffset,@loc) from TimeTran And this And this where TtUTCStart < dateadd(mi,-TtOffset,@loc) For this UTC Time Add this offset To produce this local time DST Zone and TtUTCStop >= dateadd(mi,-TtOffset,@loc) 2012-03-11 05:00 -300 2012-03-11 00:00 “ “ EST and TtDST = @dst and TtZone = @TtZone) 2012-03-11 06:00 -300 2012-03-11 01:00 “ “ EST end 2012-03-11 07:00 -240 2012-03-11 03:00 “ “ EDT create function utctoloc(@utc datetme,@TtZone smallint) returns datetime as 2012-03-11 08:00 -240 2012-03-11 04:00 “ “ EDT begin return (select dateadd(mi,TtOffset,@loc) 2012-11-04 04:00 -240 2012-11-04 00:00 “ “ EDT from TimeTran where @utc between TtUTCStart and TtUTCStop 2012-11-04 05:00 -240 2012-11-04 01:00 “ “ EDT and TtZone = @TtZone) 2012-11-04 06:00 -240 2012-11-04 02:00 “ “ EDT end 2012-11-04 07:00 -300 2012-11-04 02:00 “2” EST create function utctoloc_dst(@utc datetme,@TtZone smallint) returns char(1) as 2012-11-04 08:00 -300 2012-11-04 03:00 “ “ EST begin Figure 10. Applying the UTC time offset to produce local times. return (select TtDST from TimeTran where @utc between TtUTCStart and TtUTCStop As a new time zone moves westward to increase UTC time, the and TtZone = @TtZone) offset also increases. This preserves the relative time of the data with end respect to the time at which it was stored in the database. Once the offset have been configured, data may be selected by converting the Figure 12. Converting between local time and UTC time UTCTime attribute for the data into local time. This conversion is We can now use local time as a search argument, which pro- coded as part of the query. In addition, the local hour-ending time duces the following query: is included in the result. For data with other frequencies, derived attributes for day-ending, month-ending, and year-ending can also select UTCTime = d.UTCTime, be included. The query to select a local time is composed as follows: LocTime = dateadd(mi,TtOffset,d.UTCTime), select HE = right(“0”+convert(varchar(2),datepart(hh,dateadd( UTCTime = d.UTCTime, ms,-2,dateadd(mi,t.TtOffset,d.UTCTime)))+1,2), LocTime = dateadd(mi,TtOffset,d.UTCTime), DST = t.TtDST, HE = right(“0”+convert(varchar(2),datepart(hh,dateadd( ZoneAbbr = t.TtZoneAbbr, ms,-2,dateadd(mi,t.TtOffset,d.UTCTime)))+1,2), Value = d.Value DST = t.TtDST, from Data d, TimeTran t, TimeZone z ZoneAbbr = t.TtZoneAbbr, where d.UTCTime >= t.TtUTCStart Value = d.Value and d.UTCTime <= t.TtUTCStop from Data d, TimeTran t and t.TtZone = z.TtZone where d.UTCTime >= t.TtUTCStart and d.UTCTime > dbo.loctoutc(“11/4/12”,” “,z.TtZone) and d.UTCTime <= t.TtUTCStop and d.UTCTme <= dbo.loctoutc(“11/5/12”,” “,z.TtZone) and d.UTCTime > “2012-11-04 04:00” and z.TtName = “America/New_York”) and d.UTCTme <= “2012-11-05 05:00” order by d.UTCTime order by d.UTCTime Figure 13. Query used to select data based on local time. Figure 11. Query used to select data based on UTC time.

7 Time Translatoin Another problem, not related to time zones, is the timestamp Sydney and New York (for other dates there may be 13 or 15 hours used for midnight. Many users want to see results that consider the depending on daylight savings time): th last hour of the day as the 24 hour of the current day, whereas select Hours = datediff(hh, many database implementations of the datetime data type return (select dbo.loctoutc(“2012-05-19”,” “,Zone) the last hour as the 0th hour of the next day. Given this, how do we from TimeZoe where Name = “Australia/Sydney”), (select dbo.loctoutc(“2012-05-19”,” “,Zone) translate an internal timestamp into a useful displayable time? from TimeZone where Name = “America/New_York)) To calculate an hour-ending time in Sybase, 2 milliseconds (the smallest unit which will affect a Sybase datetime data type) are Figure 15. Calculating differences between time zones. subtracted from the local time to bring it into the previous hour. In real life, just how feasible is the approach for defining time This produces an hour from 0 to 23. Then, 1 hour is added to the zone information in a relational format, and applying this informa- hour part in order to produce an hour-ending quantity. tion within SQL query methods? It turns out this is very feasible. Having taken care of converting local to UTC time, displaying Before the TZ database, and before the Oracle-type programmatic a repeated 2 AM hour, and displaying hours from 1 through 24 database solution, directly-accessable data tables in various forms rather than 0 through 23, the output from the query in Figure 14 is (not just relational forms) were indeed used as expected. returned as follows:

UTCTime LocTime HE DST ZoneAbbr Value Conclusion 2012-11-04 05:00 2012-11-04 01:00 01 EDT 466 Even in the simplest case, where you merely need to display 2012-11-04 06:00 2012-11-04 02:00 02 EDT 578 data in your own time zone, then at the bare minimum you must 2012-11-04 07:00 2012-11-04 02:00 02 2 EST 234 consider the effect of 23, 24, and 25 hour days and the potential of 2012-11-04 08:00 2012-11-04 03:00 03 EST 723 you own time zone to implement or re-implement DST rules at any 2012-11-04 09:00 2012-11-04 04:00 04 EST 876 time in the future. Even in this minimum case, the need for storing data in UTC time and applying time translation is apparent. 2012-11-04 10:00 2012-11-04 05:00 05 EST 949 2012-11-04 11:00 2012-11-04 06:00 06 EST 307 Plans to implement time zones should be formulated very ear- 2012-11-04 12:00 2012-11-04 07:00 07 EST 376 ly in the design process, since application code could be effected by 2012-11-04 13:00 2012-11-04 08:00 08 EST 243 use of time zone API’s or time zone relations equivalent to those discussed here. If you are happy with the Oracle-type language 2012-11-04 14:00 2012-11-04 09:00 09 EST 853 implementations, then a relational solution may not be necessary. 2012-11-04 15:00 2012-11-04 10:00 10 EST 234 However, if you platform does not support time zones, or if the 2012-11-04 16:00 2012-11-04 11:00 11 EST 863 existing implementation is insufficient, then the relational solution 2012-11-04 17:00 2012-11-04 12:00 12 EST 652 described here is an alternative. 2012-11-04 18:00 2012-11-04 13:00 13 EST 425 These relational methods can also be adapted to work for an 2012-11-04 19:00 2012-11-04 14:00 14 EST 453 interval database model, where each unit of time would be repre- 2012-11-04 20:00 2012-11-04 15:00 15 EST 642 sented by two attributes, start time and stop time. In fact, any piece 2012-11-04 21:00 2012-11-04 16:00 16 EST 732 of data which contains a time stamp may qualify for time zone and 2012-11-04 22:00 2012-11-04 17:00 17 EST 727 daylight savings time treatment. 2012-11-04 23:00 2012-11-04 18:00 18 EST 723 2012-11-05 00:00 2012-11-04 19:00 19 EST 723 References 2012-11-05 01:00 2012-11-04 20:00 20 EST 135 [1] Yng, M. A. What time is it really? Retrieved from http://www. 2012-11-05 02:00 2012-11-04 21:00 21 EST 705 math.nus.edu.sg/aslaksen/teaching/timezone.html 2012-11-05 03:00 2012-11-04 22:00 22 EST 925 2012-11-05 04:00 2012-11-04 23:00 23 EST 724 [2] McCarthy, D. D. (November 1999). GPS and Leap Seconds, Time to Change? U.S. Naval Observatory, GPS World 2012-11-05 05:00 2012-11-05 00:00 24 EST 136 Figure 14. Converting from UTC time to local time. [3] Basic Time Zone Concepts. Retrieved from http://statoids. com/tconcept.html As shown, the last hour of the day is returned as hour 24 rather [4] Military and Civilian Time Designations. Retrieved from than hour 0, and all the other hours are unaffected. Note that we http://wwp.greenwichmeantime.com/info/timezone/htm can now identify the first and second 2 AM hours by the “2” indi- cator, which denotes the second 2 AM hour. Thus, both daylight [5] Sources for Time Zone and Daylight Savings Time Data. Re- savings time and hour-ending problems are solved. trieved from http://www.twinsun.com/tz/tz-link.htm Using these functions, we can also perform time arithmetic [6] Bernstein, D. J. UTC, TAI, and UNIX time. Retrieved from between local times in different time zones. For example, the query http://cr.yp.to/proto/utctai.html below will show that, on May 9th, 2012, there are 14 hours between [7] Transact-SQL User’s Guide. Sybase Adaptive Server Enter- prise, Version 15.0.

8 Time Translatoin [8] What To Do About Time Zone Dementia. Retrieved from http://gigaom.com/collaboration/what-to-do-about-time- zone-dementia/ [9] Olson, D. A. (November 24, 1986). seismo!elsie!tz; new ver- sions of time zone stuff. Retrieved from the tz mailing list [10] Working with Time Zones. W3C Working Group Note. Re- trieved from http://www.w3.org/TR/timezone [11] Datetime Datatype and Time Zone Support. Globalization Support Guide, 10g Release (10.0). Retrieved from http://download.oracle.com/docs/cd/B14117_01/serv- er.101/b10749/ch4datetime.htm [12] Koopmann, J. Oracle Time Zones. (September 12, 2003). Database Journal. Retrieved from www.databasejournal.com/ features/oracle/article.php/3072991/Oracle-Time-Zone.htm [13] Daylight Savings Time and Sybase Server Products. Technote. Retrieved from http://www.sybase.com/detail?id=1048699 [14] Seymour, B. How to Read the tz Database Source Files. Re- trieved from http://69.36.11.139/tzdb/tz-how-to.html [15] Seymour, B. A Relational View of the tz Database. Retrieved from http://69.36.11.139/tzdb/db.html#appa [16] Howse, D. Greenwich Time and the Discovery of the Longitude. Oxford University Press, London, 1980 [17] ISO 8601 Data elements and interchange formats. ISO 8601:2004 standard (3rd edition). International Organization for Standardization, Switzerland [18] Time Zone Abbreviations. Retrieved from http://www.time- anddate.com/library/abbreviations/timezones/

9 Time Translatoin