| 4.4.13 Time Zone Management: | | For many years, local offices could operate numerous servers using the local time zone. But the need for cooperative working with other parties in all parts of the world has created a new set of business requirements. | | It is a legal security obligation to record events in a sequencial time order that does not have gaps or overlaps. This demands that all servers in all locations are synchronised to GMT that is now known as UTC (Coordinated Universal Time). In aviation, Coordinated Universal Time (UTC) is known as Z-time or Zulu-time. | | Reykjavik Iceland is always on UTC time and does not use daylight saving time - the only place where time is always correct. |
| Summer Time: | | Summer or daylight saving time (DST) is synchronised to 01:00 UTC on the same dates in Europe (and the UK). Clocks are put forward on the last Sunday in March at 00:59:59 to 02:00:00 and clocks are put back (to normal) on the last Sunday in October from 01:59:59 to 01:00:00. | | The USA make the daylight saving time change at 02:00, rather than 01:00 and different states may choose different dates with second Sunday in march and first Sunday on November being a standard. Southern hemiphere are the other way round; DST clocks put back in March and put forward in October. Africa, Asia and much of South America do not bother with DST. | | The complexity and risk caused to equipment by DST is considerable and so UTC should be used to avoid any confusion. |
| Technical Requirement: | | All servers in all data centers in all parts of the world must have their local time synchrionised as UTC. This means that all events are assigned a strict date-time stamp that is true without any regard to where the event took place. | | Satellite and radio transmissions provide UTC time to milli second accuracy for computers, aircraft, weather and business systems that must never be confused by daylight saving time and time zones. A key benefit is that UTC time never has gaps and never goes backwards and is accepted by every country in the world. |
| Software: | | Date and time functions are provided to determine the local time for a user in a specific time zone on a specific date. When saving date and time, then UTC is employed as the default - date and time must be recoded as a pair of field values as time is always dependent on the date. When formatting date and time for a specific user, that users time zone is part of the formating calculation. | | While most operating systmes use UTC internally, Windows only supports local time and this causes problems with dual boot machines where time us UTC in the other operating systems. |
| | | User Requirement: | | Each user in each office may have their own local time zone that may be subject to summer time variations on different dates. For any specific user, that users time zone is known and the event date will determine if summer time offset should be applied. Each user can be shown timed events according to their own local clock, however all such time is derived from UTC as the world wide base value. |
| User Profile: | | Each user profile is associated with one office profile that identifies the time zone of that office - each office must exist in one time zone. This timezone field enables application services to display the applicable local time to each user. This calculation may include an allowance for daylight saving or summer time. |
|