| 2.2 Service Level
11. Service Time Zone | |
|---|
| 2.2.11 Service Time Zone: | | While Microsoft, Amazon and Salesforce imagine that they are Application Service Providers, we provide a much higher quality of application services with continual improvements, continual monitoring and continual administration. By fully understanding exactly what our customers want, we are able to deliver a lot more services that our competition do not understand. |
| Timezones: | | We provide application services to users that span many timezones, many languages and many currencies. | | We understand that each user wishes to see their own local time displayed, however for data integrity purposes, all time values must be recorded as GMT. | | Where a user in Los Angeles enters a transaction at 10:23 local Pacific time, it is recorded as 19:23 GMT. | | When a user in Paris views the transaction entered in Los Angeles, it is shown as 20:23 CET as the equivalent Central European Time. |
| Technical Design: | | All racks of servers in all data centers in any county have their internal clocks synchronised to GMT and summer time is ignored. All servers record GMT as a progressive time without going backwards or having gaps - this is a world wide base line for servers in all parts of the world. | | Application services are provided to display local time to users based on their timezone and country specific summer time adjustments. | | A critical compliance requirement is that audit trails record time in a progressive way to eliminate the possibility of fraud. By always having all servers in all data centers synchronised to GMT, all audit trails provide a consistent progressive trail of events without duplication or time gaps. |
| Data Design: | | Time is always recorded in association with a data and user field value - time cannot exist as a lone field value. Time is recorded and stored as HHMMSSTH as 8 digits with 2 digits as the hour, 2 digits as the minute, 2 digits as the second and 2 optional digits as tenths and hundreths of a second. | | Time is stored as GMT but may be displayed to each user according to their own local timezone. A user in Hamburg wants to view events in Central European Time (CET) no matter what time it was where the event took place anywhere in the world. |
| User Profile: | | Each user has an assigned timezone and country that may be changed from time to time. | | Each user is part of a group that has an assigned timezone and country where the group may be a branch office, department, team, site, country or any other grouping. |
| Timezone Service: | | When a user signs in, the user timezone and user country are identified in their profile and stored as a session variable. The user timezone is used to change each GMT time field value to the users local time. The user country and associated date field value are used to change the local time based on summer time adjustments that may have been in force in that country on that date. | | The data design requirement is to always have an associated date so summer time adjustment can be calculated. It is not practical to provide a world wide application service without a proper implementation of timezone services. |
|
|