Introduction

In General

There are many different time zones. There are some time zones which are not country-specific, e.g., GMT +12, GMT +11, ..., GMT -14 and there are currently about 451 country-specific time zones, e.g., America/New_York (-5h), Europe/London (+-0h), Europe/Berlin (+1h), Australia/Sydney (+10h) etc. When it is 12:00 pm in Europe/London, it is 7:00 am in America/New_York, 01:00 pm in Europe/Berlin, and 10:00 pm in Australia/Sydney. In many countries, they have a daylight saving time which starts and ends on a country-specific date. With all these rules it is difficult for shop managers to convert a time from the local time zone into another country-specific time zone. This is why we introduce time zones.

How It Works

The back office user sets their own back office time zone and the channel time zone for the storefront. All dates which are stored in the DB are UTC-based. This means that a date is not stored for a specific time zone. To display this date in the configured time zone, it must be transformed into a date of this time zone. This transformed date is for informational use only and must not be used to control pages, pagelets, promotions, products, etc.

References

More about time zones and daylight saving time can be found in Wikipedia:
Wikipedia: Time Zone
Wikipedia: Daylight saving time

The new TimeZoneBO uses the following time zone classes from Java and Joda time:
Java API: TimeZone
Joda API: DateTimeZone

TimeZoneBO Overview

The TimeZoneBORepository:
The TimeZoneBORepository creates the TimeZoneBO_s and supports useful methods to get the TimeZoneBO you want.

The method getAllTimeZoneBOs() returns a sorted collection of all time zones available in Java. The repository uses the given or (if no one is available) the default comparator for the sorting. Another comparator can sort this list in a different way. It is possible that the server time zone or an imported time zone is not part of a filtered time zones list. So we cannot filter this list because this would mean that one or more time zones which are already set are not on this list. This is why the filtering of time zones must be done later with the help of the TimeZoneBOOffsetViewExtension.

The TimeZoneBO:
The TimeZoneBO uses the Java TimeZone class and the Joda DateTimeZone class for the following methods:

• getID(): The ID is the identifier of this time zone. The IDs of the new time zones consist of the continent and the capital city, e.g., Europe/Berlin.
• getName(): The name is the long TimeZone name, e.g., "Central European Summer Time".
• getOffset(): The offset is the time in milliseconds which must be added to the UTC time to get the current date or the given date.
• getRawOffset(): Other than the normal offset, there is the RawOffset which ignores the daylight saving time.
• hasDaylightTime(): This method returns true if the current time zone has a daylight saving time (DST), otherwise it is false. So you can find out if you must consider the DST or not.
• isInDaylightTime(): When hasDaylightTime() is true and when the time zone is currently in the DST, the method isInDaylightTime() returns true, otherwise it is false. If you assign a date to this method, it runs this test with the given date.

The TimeZoneBOExtension:
The TimeZoneBOExtension has two methods which determine the description and the enabled status:

• getDescription(): This method returns the description of a time zone. The description will be generated from a given or (if no one is available) the default descriptor. The default descriptor returns a description which has the following format: "(GMT {formatted RawOffset}) {continent}/{capital city}". Another descriptor can return a different description.
• isEnabled(): This method returns the enabled status of a time zone which is required to filter the time zone list. The enabled status will be determined from a given or (if no one is available) the default predicate. The default predicate returns true if the ID of a time zone starts with the continents Africa, America, Asia, Atlantic, Australia, Europe, Indian, or Pacific, otherwise it returns false. But another predicate can do this in a different way with a different result.
  Since the usage of the description and the enabled flag are application-specific, it must be done inside this extension which is optional and does not need to be created via the corresponding factory.

The Factories:
The factories "TimeZoneBORepositoryExtensionFactory" and "TimeZoneBOOffsetViewExtensionFactory" are component implementations which create the corresponding extensions. To use these extensions, it is necessary to instantiate the factories and assign them to the extension factories.

TimeZoneBO Usage

Overview

The pipeline ProcessTimeZones-DetermineSessionTimeZoneBO implements the fallback for TimeZoneBO of the back office and the storefront. So this pipeline returns the TimeZoneBO for the current session. Everyone who wants to know the current time zone must use this pipeline.

Since there is no need to display all enabled time zones in the storefront, the TimeZoneBOOffsetViewExtension is only available in the back office.

Inheritance of Time Zone Settings

All TimeZone values with the exception of the Server TimeZone can be set to null. This is why we need a fallback. If the Back office Session TimeZone is set to null, we take the next value on the list. In this case it is the User TimeZone. When the User TimeZone is null, we fall back to the Server TimeZone. The following image shows the overview of all TimeZone Fallbacks.

The creation process (blue) of a Back office User or a Consumer Channel initializes the time zone ID with the ID of the Server TimeZone. So only in exceptional cases will the fallback to the Server TimeZone be done.