Kbase P181357: Do DATETIME and DATETIME-TZ data types reflect changes in Daylight Savings Time rules?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
02/02/2011 |
|
Status: Unverified
GOAL:
Do DATETIME and DATETIME-TZ data types reflect changes in Daylight Savings Time rules?
GOAL:
Does the DATETIME-TZ data-type take into account daylight savings rules?
GOAL:
Does the DATETIME-TZ data-type take into account daylight savings rules?
GOAL:
Does the datetime data-type take into account daylight savings rules?
GOAL:
Is OpenEdge compliant with current and past daylight savings rules?
FACT(s) (Environment):
All Supported Operating Systems
OpenEdge 10.x
FIX:
The DATETIME and DATETIME-TZ data types in the ABL provide a means of storing date and time values in a field or variable and ensures complicity with the rules as applied to the underlying operating system upon which the session is running.
When using the type with the time zone (-TZ) component, the time zone offset is extracted from the local operating system in order to return/store the correct value.
The DATETIME-TZ function can be used to display the correlative date and time in other time zones by specifying the appropriate UTC offset (in minutes) as the last (optional) argument.
What this can not do is extrapolate the correct offset for any region outside of the one on which the local session is running. This is subject to the rules applied by any country, state or other governing entity which governs the daylight savings rules for that region.
For instance; if you have a datetime-tz value stored in your database and it was stored in EDT, the offset would be -05:00 or -300. Let's say an application requirement causes the need for the time to be displayed in Belgian local time and you *know* the UTC offset for Belgium for that given time period. In this case you could use the DATETIME-TZ function to convert the time to the given offset, thus reflecting the time local to that region. However, if you are not aware of what the UTC offset was for that region during that period in time, OpenEdge offers you no direct affordance to determine this value.
These rules are subject to frequent change and may be very subjective so no language could account for these changes without constant maintenance and updates to a repository of such rules which would likely be keyed off of country, state or some other value such as map coordinates.
There are businesses that exist that supply this functionality through web services portals and/or downloadable databases or applications, both for free and for pay, that one may opt to take advantage of.