There are some considerations you need to take into account when TimeZone Support is enabled.
The corresponding TZ offset is applied when the date and time are available. If any of them is missing, such as in Time domain, Date data type or DateTime data type attributes with only the Time part enabled (0:X), the offset cannot be made.
- Application server and database server share the same timezone
The application and database servers are assumed to be in the same TZ: that of the application server. If the DB server has a different TZ, issues could happen when using ServerNow Function and/or ServerDate Function.
- Access to data from other applications
All DateTime fields of a DB are assumed to be in the TZ indicated by the DateTime storage timezone property. This should be taken into account if the data is queried or updated by other applications.
All DateTime fields of External Object: Native Object are assumed to be in CTZ format. This should be taken into account when integrating native classes.
- Object's navigation considerations
When TimeZone Support is enabled, the following set of functions is not evaluated in the Database Server (optimized) due to DST.
- Hour Function, Hour Method,
- Day function, Day method,
- Month function, Month method,
- Year function, Year method,
- Dow function, DayOfWeek method,
- EoM function, EndOfMonth Method,
- Minute Function, Minute Method,
- YMDHMStoT function
- DST adjustment for DateTime values prior to 1970 may not be correct!
- In the Date Time storage timezone property you must set a valid Timezone included in the Olson table (IANA time zone database), if you set a "custom" Time Zone (not included in the Olson table) the "Name 'Standard time Montevideo' not found in zoneinfo directory" (see SAC 38552)
TimeZone Support - DateTime handling