jdp-2020-01: Extended Time Zone Types Support
- Published: 2020-03-07
- Implemented in: Jaybird 4
Firebird 4 snapshot 188.8.131.525 introduces two 'bind-only' data types,
EXTENDED TIME WITH ZONE and
EXTENDED TIMESTAMP WITH TIME ZONE. These new types have an
extra signed short with the time zone offset in minutes (serialized as 4 extra
bytes in the wire protocol). For offset based types, the offset is present twice,
for named zones, the offset is present in addition to the zone identifier.
These data types are intended to address concerns for clients that do not or cannot resolve the named zones, but do not want to fallback to UTC time and instead want to preserve the actual offset.
These types are only surfaced through
Jaybird will add minimal support for these 'extended' time zone types by handling them exactly the same as the normal time zone types. This effectively means that the secondary offset information will always be ignored.
The following options were considered but rejected:
Using the extra offset information to determine the offset.
As we need to support the normal time zone types as well, this would add more complexity to derive the same information.
Do option 1, and always map to the 'extended' types using
This would allow us to uniformly handle with time zone types by always using the secondary offset information. This would remove the need for handling named zones in Jaybird.
As users could manually change the bind to the normal time zone types, we would still need some form of support of the normal time zone types, for example only supporting the offset types or always falling back to UTC.
Although option 2 could simplify code in Jaybird, considering we'd need some form of support of the normal time zone types, the support for those normal types already exists, the core developers consider the 'extended' types a temporary or transitional feature, and the extra 4 bytes overhead in the wire protocol, made us decide to reject these options (where we consider option 1 a subset of option 2).
Jaybird will provide minimal support for
EXTENDED TIME(STAMP) WITH TIME ZONE,
by always handling it is their normal
TIME(STAMP) WITH TIME ZONE counterpart.
In a situation where Jaybird cannot determine the offset of a named zone, this means we will fallback to UTC, just like we do for the normal time zone types. This also preserves consistency between 'extended' and normal types (eg in situations where Jaybird and Firebird might disagree how to derive the offset for a named zone).
We recommend users not to set their binds to the 'extended' types, but if they do its behaviour will be identical.