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.
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.
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
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 uses the Java TimeZone class and the Joda DateTimeZone class for the following methods:
The TimeZoneBOExtension has two methods which determine the description and the enabled status:
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.
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.
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.
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.