Add session time zone to system context

[mrotteveel]

Currently it is not possible to obtain the current session time zone other than through workarounds like substring(current_timestamp from 26).

I think we should add:

• RDB$GET_CONTEXT('SYSTEM', 'SESSION_TIME_ZONE')
• MON$TIME_ZONE in MON$ATTACHMENTS

Both should return the current session time zone (either named zone or offset in {+|-}HH:MM).

This would be similar to what is provided for the session idle timeout, which is accessible from the system context using RDB$GET_CONTEXT('SYSTEM', 'SESSION_IDLE_TIMEOUT') and from MON$IDLE_TIMEOUT in MON$ATTACHMENTS.

Desired situation:

set time zone 'America/New_York';
select RDB$GET_CONTEXT('SYSTEM', 'SESSION_TIME_ZONE') from rdb$database;
-- returns 'America/New_York'
select MON$TIME_ZONE from MON$ATTACHMENTS where MON$ATTACHMENT_ID = CURRENT_CONNECTION;
-- returns 'America/New_York'

and

set time zone '+01:00';
select RDB$GET_CONTEXT('SYSTEM', 'SESSION_TIME_ZONE') from rdb$database;
-- returns '+01:00'
select MON$TIME_ZONE from MON$ATTACHMENTS where MON$ATTACHMENT_ID = CURRENT_CONNECTION;
-- returns '+01:00'

[asfernandes]

MON$TIME_ZONE in MON$ATTACHMENTS

This is overkill IMO as the information is already present in MON$TIMESTAMP.

We should better add extension to EXTRACT returning region string and let people use that EXTRACT extension with MON$TIMESTAMP.

[asfernandes]

The standard EXTRACT uses TIMEZONE_HOUR and TIMEZONE_MINUTE while others commands uses TIME ZONE separated. What a bad thing.

[hvlad]

MON$TIME_ZONE in MON$ATTACHMENTS

This is overkill IMO as the information is already present in MON$TIMESTAMP.

We should better add extension to EXTRACT returning region string and let people use that EXTRACT extension with MON$TIMESTAMP.

Agree

[aafemt]

Isn't MON$TIMESTAMP connection time? Will it be changed after "SET TIME ZONE" issued?

[mrotteveel]

MON$TIME_ZONE in MON$ATTACHMENTS

This is overkill IMO as the information is already present in MON$TIMESTAMP.

We should better add extension to EXTRACT returning region string and let people use that EXTRACT extension with MON$TIMESTAMP.

Except it isn't available in MON$TIMESTAMP, the timestamp is always in the server time zone

select cast(mon$timestamp as varchar(50)) from mon$attachments where mon$attachment_id = current_connection;
-- Output: 2021-05-03 13:11:22.7720 Europe/Amsterdam
set time zone 'America/New_York';
select cast(mon$timestamp as varchar(50)) from mon$attachments where mon$attachment_id = current_connection;
-- Output: 2021-05-03 13:11:22.7720 Europe/Amsterdam

After connecting with isc_dpb_session_time_zone set to America/New_York:

select cast(mon$timestamp as varchar(50)) from mon$attachments where mon$attachment_id = current_connection;
-- Output: 2021-05-03 14:38:31.7910 Europe/Amsterdam

[mrotteveel]

And to be clear, this isn't just about getting the time zone, it is also about providing a consistent API. That is, if session idle timeout is available from RDB$GET_CONTEXT and MON$ATTACHMENTS, then so should the session time zone.

[asfernandes]

Except it doesn't, the timestamp is always in the server time zone

So I think we should change it to use isc_dpb_session_time_zone when it was set.

Isn't MON$TIMESTAMP connection time? Will it be changed after "SET TIME ZONE" issued?

It should not be changed, but should it be a real problem?

[mrotteveel]

Except it doesn't, the timestamp is always in the server time zone

So I think we should change it to use isc_dpb_session_time_zone when it was set.

I don't see why it should. That column provides when the server received the connection. Having this report it in the time zone of the server is perfectly fine and logical. Changing it to reflect the current session time zone sounds like an abuse to avoid creating a logical API.

[asfernandes]

And to be clear, this isn't just about getting the time zone, it is also about providing a consistent API. That is, if session idle timeout is available from RDB$GET_CONTEXT and MON$ATTACHMENTS, then so should the session time zone.

So you do not want to solve any real problem?

Then there is more work for you (how do one read set bindinds, etc).

[hvlad]

EXTRACT allows to work with any timestamp, from any source. It is more general and I see no reason to not implement it.
I'm not objecting extending of system context, but in this case more generic solution exists and it is always preferred, imo.

As for:

MON$TIMESTAMP, the timestamp is always in the server time zone

use current_timestamp, not mon$timestamp

[mrotteveel]

And to be clear, this isn't just about getting the time zone, it is also about providing a consistent API. That is, if session idle timeout is available from RDB$GET_CONTEXT and MON$ATTACHMENTS, then so should the session time zone.

So you do not want to solve any real problem?

I'm currently updating the Language Reference, and I foresee and expect that people will want to know this information.

Then there is more work for you (how do one read set bindinds, etc).

Well, yes, I argue those should also be exposed as well. Personally, I'd be fine with exposing this only through RDB$GET_CONTEXT, but on the other hand the case of the session idle timeout being exposed through both RDB$GET_CONTEXT and MON$ATTACHMENTS argues that the rest should too if only for API consistency and to make this information available to adminstrators about other connections.