Reader small image

You're reading from  Developing Robust Date and Time Oriented Applications in Oracle Cloud

Product typeBook
Published inMay 2023
PublisherPackt
ISBN-139781804611869
Edition1st Edition
Concepts
Right arrow
Author (1)
Michal Kvet
Michal Kvet
author image
Michal Kvet

Michal Kvet is a researcher, educator, and database expert at the University of Žilina in Slovakia. His primary focus areas are databases, analytics, performance, and cloud computing. He works closely with Oracle and Oracle Academy. He is the co-author of multiple textbooks (a SQL and PL/SQL cookbook, a book on APEX application development, a book on temporal databases, and a MySQL cookbook), coordinates multiple Erasmus+ projects and co-organizes several research conferences and database workshops. Besides this, he supervises engineering projects and bachelor's, master's, and doctoral theses. Over the years, his research has been associated with date and time management and temporal databases. He has Oracle's SQL, PL/SQL, Cloud, Analytics, and Administration certifications. His core knowledge of temporality is provided to you in this book.
Read more about Michal Kvet

Right arrow

Concepts of Temporality

In the last chapter, we dealt with the ISO 8601 standard, focusing on the data perspective, modeling principles, and individual element handling. This chapter goes deeper into the concepts related to temporality and the core background facts influencing temporality.

Everyone knows that when seasons shift, either to summer or winter time, the number of hours in a specific day also changes. The day can either change to 25 or 23 hours. In one case, we look forward to sleeping longer; in the other, we will sleep for fewer hours. This change factor is also related to time zones, which you will feel especially when traveling. Another real-world issue relates to Christmas. When do you celebrate Christmas, according to the Gregorian or Julian calendar? In fact, what are the key differences between calendars, and what do they actually affect? How does using a particular type of calendar affect leap years? These are practical questions to which we will find answers...

What is temporality?

What does the term temporality mean? Is it the logical concept or the physical model supported by the infrastructure? Or can it just be defined by a set of rules that must be applied? Well, it does not reflect a specific model or implementation. Instead, temporality covers any solution that deals with time. Namely, each object state (data tuple) can be positioned on a timeline. Thus, each object is delimited by multiple states valid during the specified period of time. Generally speaking, relational databases can be automatically considered to be partially temporal, whereas each data change is always encapsulated by the transaction. And each transaction generates data change vectors stored in the transaction logs. So, what does it actually mean? Such a transaction log structure clearly denotes the object state history, doesn´t it? Thus, the transactional databases can produce states valid in the past. However, it is not as simple as it may seem at first glance...

Introducing DST

DST (also referred to as Daylight Time in the US, Canada, and Australia and Summer Time in the United Kingdom and European Union) is a technique of time change during the summer months to adapt to natural light so that twilight occurs at a later time of the day (typically an hour later). As a result, one day, typically in October or November, has 25 hours (fall back), whereas one day in spring has only 23 hours (spring forward). This change brings economic benefits. But on days with time changes, issues often arise related to transport, industry, and non-stop working shifts. The information technology (IT) sphere commonly manages DST automatically without requiring any user intervention.

The correct definition of DST is Daylight Saving Time, but in older literature, the term Daylight Savings Time (with an s at the end of Savings) is used. It may also be seen in modern references, as many editors still prefer the original form. The other acceptable forms are Daylight...

Introducing UTC

UTC is a time representation that applies zero offsets. It is then used as a reference for other time zones. UTC representation is denoted either by the symbol UTC placed after the time specification (for example, 08:30 UTC) or by using an empty time zone specification Z (for example, 8:30Z).

UTC is the primary standard for dealing with time management and representations. It regulates and synchronizes clocks and time. It references Greenwich Mean Time (GMT) and does not depend on DST. It was first used in 1960, followed by the standardization in 1963, introducing the official abbreviation – UTC. It was updated in 1970 to cover the leap second.

UTC is divided into individual day, hour, minute, and second elements. Days are identified by the Gregorian calendar reference, but the Julian day numbers can also be used (the transformation principles are described in the Gregorian versus Julian calendar section). Each day contains 24 hours. Each hour consists...

Time zone perspective

Oracle cloud database instances use UTC date and time references by default. Although it is strongly recommended to use UTC to simplify time zone management, shifts, and calculations and avoid data conversions, users can change the base time zone reference in the cloud console or by using APIs.

The standard usage of UTC arises from ISO 8601, which covers time zone management by using the values offset from UTC for local values.

When dealing with a complex system accessed across regions and multiple time zones, the server and client perspectives will inevitably need to be distinguished. The server, like the client, can be located anywhere in the world. However, the locations themselves are important for the correct determination of time zones and transformations between them. Thanks to that, it is possible to obtain and process time from the client’s point of view, as well as the server’s. Consequently, all values are linked to the time zone...

Gregorian versus Julian calendar

The Gregorian calendar is currently commonly used, based on the already-specified principle of leap year management. The Gregorian calendar was introduced by Pope Gregory XIII in 1582. The aim was to apply date shift properly (one year does not take exactly 365.25 days, so the leap year should not be applied once in four years generally), respecting the Earth’s speed. This way, proper day mapping over the centuries can be ensured.

The Julian calendar was established in 46 BC by Julius Caesar as an update to the Roman calendar, which used 29 days for most months, by introducing an extra intercalary month between February and March. Note that this intercalary month is not applied every year but only for those years that are marked as intercalary years). It was used up to 1582. Then, it was replaced by the Gregorian calendar. The main difference in these calendars is related to the year definition. The Julian calendar has two types of year &...

Leap years in the Gregorian calendar

The orbit of the Earth around the Sun takes a little more than 365 days (precisely 365.2422 days). As a result, some adjustments must be applied to keep the seasons correct. Namely, it is necessary to maintain correctness so that even in many years, decades, and centuries, it will be possible to apply the same rules for individual days and the position of the Sun from a calendar perspective.

Leap years are used periodically to decrease the difference between the calendar year and the Earth’s real rotation and to ensure year-over-year mapping. How do we identify a leap year? Well, if the year value can be divided by four without any remainder, then that year can be considered a leap year. That is true just for the Julian calendar, but the Gregorian calendar applies additional rules that ensure that the number of leap years is lowered. Namely, the year number must be divisible by four, except for the first year of the century (divisible...

Leap second

A leap second is characterized by a specific situation. Commonly, a minute lasts 60 seconds, but when a leap second occurs, 1 minute lasts either 61 seconds or 59 seconds. The leap second is applied occasionally without specific planning. This decision is made by the IERS to accommodate the difference between the high-precision atomic clock time and solar time that reflects the natural Earth’s movement (commonly referred to by the abbreviation UT1). As stated, the common reference in civil environments is UTC; however, as the Earth’s rotation speed varies according to climate and geological events, it is necessary to apply a leap second occasionally to ensure the difference between UTC and UT1 does not exceed 0.9 seconds. Typically, the leap second announcement is made approximately six months before its physical occurrence. It is commonly associated with the last day of the month. June or December is preferred if a leap second needs to be applied to a year...

Summary

Until now, you may have felt that the world of time management was simple. A day has 24 hours, and a year consists of 365 days. In this chapter, we have shown that there is 1 day of the year that has only 23 hours and one that has 25 hours because of the transition to summer and winter time, described as DST. Similarly, although a standard year is made up of 365 days, there is also a leap year in which there is 1 extra day. The difference between the Julian and Gregorian calendars and the related leap year occurrence was also discussed.

Time zones are an integral part of the calendar and time. In the past, information systems were only local – server and client time were always the same. The client and server were in the same time zone within one small geographical area. With the globalization of systems, markets, and businesses, it is necessary to pay attention to time zones and transitions between them. We have described the concept of UTC, which is used for time...

Questions

  1. Which time zone perspective is commonly used for date and time value normalization with no offset?
    1. UTC
    2. CET
    3. CEST
    4. BST
  2. If the database time is 11:47 UTC and the client time zone is +02:00, which of the following is the correct expression for the client time?
    1. 13:47
    2. 11:47 UTC
    3. 11:47 +02:00
    4. 13:47 +02:00
  3. Which calendar’s definition of a year (including leap years) most accurately represents the Earth’s rotation around the Sun?
    1. Roman calendar
    2. Julian calendar
    3. Gregorian calendar
    4. Normalized calendar
  4. Try to solve this problem before moving on to learning about the core elements of Oracle database implementation in the next chapter:

My friend was 17 years old 2 days ago. Next year, he will be 20. What is the date today?

Further reading

  • What Is Daylight Saving Time? by Anne Buckle and Vigdis Hocken provides you with interesting historical details and principles of DST. By reading the text, you will gain a deeper understanding of DST specifications such as rules for identifying dates when winter time shifts to summer time or vice versa. It also provides an interesting background to the evolution of DST. For example, did you know the DST time change can be 30 or 45 minutes rather than 1 hour? Which country was the first to use DST? The answer can be found in the paper available at https://www.timeanddate.com/time/dst/. Get inspired.
lock icon
The rest of the chapter is locked
You have been reading a chapter from
Developing Robust Date and Time Oriented Applications in Oracle Cloud
Published in: May 2023Publisher: PacktISBN-13: 9781804611869
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
undefined
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $15.99/month. Cancel anytime

Author (1)

author image
Michal Kvet

Michal Kvet is a researcher, educator, and database expert at the University of Žilina in Slovakia. His primary focus areas are databases, analytics, performance, and cloud computing. He works closely with Oracle and Oracle Academy. He is the co-author of multiple textbooks (a SQL and PL/SQL cookbook, a book on APEX application development, a book on temporal databases, and a MySQL cookbook), coordinates multiple Erasmus+ projects and co-organizes several research conferences and database workshops. Besides this, he supervises engineering projects and bachelor's, master's, and doctoral theses. Over the years, his research has been associated with date and time management and temporal databases. He has Oracle's SQL, PL/SQL, Cloud, Analytics, and Administration certifications. His core knowledge of temporality is provided to you in this book.
Read more about Michal Kvet