What is time zone offset

If I want to talk to a friend at 6 p. This shorthand from time zone to offset works in everyday life, but it gets us mixed up when the difference between time zones and offsets matters in programming. My home state, Indiana, is a site of hot debate about whether all or parts of the state should be on Eastern Standard Time , Eastern Daylight Saving Time sometimes, sometimes , or Central Time The debates in Indiana involve everything from reducing two-hour school delays in the winter to syncing with Wall Street versus Chicago, to how late the kids have to stay up for fireworks shows in July.

I can delight in all this mess or tear my hair out, and I choose to delight in it! You can read about all the other ones here. If you ask too many questions about what exactly UTC is, you will run into the fact that naming moments in time is a human thing we made up. If you want something to distract you from existential confusion, may I suggest learning about UNIX timestamps?

That was pretty enlightening. Thanks for doing this blog post. Timezones, timestamps, offsets, etc. This really helps put things into perspective. Thanks for making time and dates just a little less confusing. I know I was using offsets and time zones interchangeably, but no more! Wish I would have found this much sooner! We're Hiring. Atomic Object. By: Devney Hamilton. About This Author It has been said many times, many ways: Offsets are not time zones, and time zones are not offsets!

Breaking Down the Difference A time zone is a place. In fact, the map above pointing out Coral Harbor and Detroit is a map of time zones around the world.

These are abbreviations for offsets that are loosely tied to place. Another Nuance Why are there so many time zones that seem to share the same offset? Why the Confusion? For example, incremental times can be directly compared—their integer values determine which is earlier or later—while field based times must be normalized and their individual fields compared. Field based times can have certain kinds of logical operations performed on them for example, rolling the date forward or back , while incremental time requires a logical transformation.

For example, to set the date forward by one day, an implementation can add 'one unit' to the "day" field and adjust the month and year as appropriate. The SQL data types date , time , and timestamp are field based time values which are intended to be zone offset independent.

The data type timestamp with timezone is the zone offset-dependent equivalent of timestamp in SQL. Programming languages, by contrast, tend to use incremental time and convert to and from a localized textual representation on demand. Databases may use incremental time or either zone offset-dependent or independent field-based structures internally.

For example, an Oracle 8 database treats a timestamp field as though it is in the local time of the database instance.

As a result, users may not be clear on the differences between these types or may create a mixture of different representations. Date objects from a database, even though the actual field in the database is a field-based timestamp value. UTC is indicated by the letter Z for example Z. Or, the zone offset may be omitted completely.

If the two types are mixed, then the interpretation of the zone offset is not adequately specified in XML Schema. In XQuery 1. This is usually either UTC or local time. The presence or absence of the zone offset in the XML Schema representation may not be indicative of the original data's intention because of the confusion described above.

Proper comparisons or processing rely on normalizing all date and time values into zone offset-independent or zone offset-dependent forms and never mixing the two in a particular operation. This section describes different guidelines that can be applied to various time and date comparisons. Field-based time and date values require the user to determine whether to use a fixed zone offset, a time zone, or nothing. While XML Schema times are field-based in terms of the lexical representation, the underlying data may use incremental time, as may the implementation processing the values.

Each specific case requires specific handling. If all of the data values represent incremental time, then the user should always use a specific zone offset and UTC is strongly recommended as this offset, since most incremental time systems are based on it and should always specify that zone offset. Values that do not specify a zone offset should be treated as if they use the same offset. If UTC is used, this produces the least amount of modification in the data. If all of the data values represent time zone independent values such as a list of employee's birth dates , then the zone offset should always be omitted.

Any values that have a zone offset should probably ignore the zone offset actually stripping it off, if possible , since zone changes are probably an artifact of other processing. If a zone offset must absolutely be applied to the data, then UTC should be used. If all of the data values represent time zone dependent values, then the zone offset must always be supplied. Great care should be used to ensure that the correct offset is used and not just the current zone offset.

For example, if a system in the U. If there are time values with no date portion with a fixed UTC offset, then the zone offset should always be indicated if and only if the time value really is fixed. That is, this would not apply to a meeting scheduled in Pacific Time, but would apply to a meeting that is always UTC and thus at in the morning in Pacific time during parts of the year.

Documents or systems can also choose to accompany a time value with the appropriate time zone identifier or TZID using a complex type. This is very important with recurring times, such as calendar meeting times. If a regular meeting is at " Pacific Time", it is insufficient to store and interchange just a zone offset. If both the date and time are fixed T , then this can be done by computing the offsets on that date and at those times, using the TZ database.

This order then reflects whether one datetime is absolutely before another. The simplest comparison mechanism where the dates may not be fully specified is simply to put both in canonical form, then order them first by time then by TZID alphabetical, caseless order.

The Olson database does not maintain a fixed canonical form; however, CLDR does provide such a form see:. However, there are cases where this mechanism results in a partial ordering. Time zone identification in the date and time types relies entirely on time zone offset from UTC. It is up to the document designer to keep the TZID in a separate data field from the time value.

Conversion between or operations on data sets that mix values with and without zone offsets present certain problems. It is good practice to use an explicit zone offset wherever possible. If one is not available, best practice is to use UTC as the implicit zone offset for conversions of this nature.

This is because the values are exactly centered in the range of possibilities and because representation internally as computer time is usually based on UTC. Since a single reference point has been used it may be possible to unwind the change later even if erroneous conversion takes place. When working with multiple documents from various sources, the "implicit" offset of the document may vary widely from that of the implementation doing the processing.

If UTC is widely used, the chances of error are reduced. Content and query authors are warned that comparing or processing dateTimes with and without time offsets may produce odd results and such processing should be avoided whenever possible. Generating content that omits zone offset information where it exists is a recipe for errors later.

Of course, data such as the SQL types cited earlier which is meant to represent wall time should continue to omit the zone offset. Query writers can check for the presence or absence of zone offset and should do so to modify dates and times explicitly instead of allowing implicit conversion whenever possible. Users of XQuery 1. Sooner or later some data will be affected by the issues described:.

Do not apply operations based on date or time types such as indexing to collections of data in which some data items may have zone offset information and other data items may not have zone offset information. If you have data that includes implicit and fixed explicit zone offsets, before applying any date- or time-sensitive operations adjust the zone offset of the implicit data to UTC with the functions for zone offset adjustment, cf.

Abstract This document discusses some of the problems encountered when working with the date , time , and dateTime values from XML Schema when those value include or omit time zone offsets. Status of this Document This document is an editors' copy that has no official standing. Note: Users and implementers of languages or specifications which handle time-related data should take the following recommendations into account even if time-zone-sensitive data is rarely used.