| Version 2 (modified by , 15 years ago) ( diff ) |
|---|
Time
Introduction
This blueprint deals with the methods for storing times.
Saving Times
All times will be converted into UTC before being saved in the database.
Time Settings
Server UTC Offset The time difference between the computer on which the instance is installed (whether it is a server or a normal PC/Laptop) and UTC. This needs to be set by the admin installing the instance. Q: Would it be possible to write some JS that checks the time on the server against UTC and automatically calculates the offset? Would require internet.
Default User UTC Time Offset The default time difference between most users and UTC.
User UTC Time Offset (This will override the Default User UTC Time Offset if specified for a user) The time difference between a specific user and UTC. Q: Would it be possible to write some JS that checks the time on the user's computer against UTC and automatically calculates the offset? Would require internet.
The Issue of Absolute vs. Relative Times
Where time data is used by the framework of the data, eg. for synchronization absolute (UTC) times should be used. However in some cases data entered by the users will contain time data about an event which is relative to the time zone.
Use Case:
A security incident is reported in Afghanistan at 10.47am local time. A security analyst would want to know the local time that happened (as well as perhaps the UTC time).
Solutions:
- Tag ALL time data with the UTC offset
| + | - |
| Bulletproof | Time consuming to implement |
| Extra data overhead when not required |
- Make sure that any table which contains time data which is relative, also contains a location where the , which includes UTC offset data.
| + | - |
| No framework mods req. | requires specific implementation each time |
It may also be useful to have some sort of flag/config setting that allows the time to be displayed as local/local relative to where it occured/UTC
