[ 
https://issues.apache.org/jira/browse/IGNITE-19274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-19274:
--------------------------------------
    Description: 
The {{TIMESTAMP WITH LOCAL TIME ZONE}} data type is a variant of {{TIMESTAMP}} 
that includes a time zone offset in its value. Data stored in the database is 
normalized to the database time zone (UTC) and time zone offset is not stored 
as part of the column data. When the data is retrieved, it to be returned in 
the user's local session time zone.

i.e:
{noformat}
CREATE TABLE timestamp(ts TIMESTAMP, t_tz TIMESTAMP WITH LOCAL TIME ZONE);
SET TIME ZONE 'tz1';
INSERT INTO timestamp VALUES ('2011-01-01 01:01:01', TIMESTAMP WITH LOCAL TIME 
ZONE '2011-01-01 01:01:01');
SET TIME ZONE 'tz2';
INSERT INTO timestamp VALUES ('2011-01-01 01:01:01', TIMESTAMP WITH LOCAL TIME 
ZONE '2011-01-01 01:01:01');
...
select * from timestamp;{noformat}
returned rows need to be different in case of different tz1 and tz2 offsets but 
they are equals for now. Also returned representation need to be present in 
user session time zone.

h5. Update from 26.02.2024:

Definition of done for this task:

* Client time zone is passed to server (check other database implementations to 
decide how and when to pass it).
* Data of type "TIMESTAMP With LOCAL TIME ZONE" can be written/read correctly 
using the dynamic parameter.


  was:
The {{TIMESTAMP WITH LOCAL TIME ZONE}} data type is a variant of {{TIMESTAMP}} 
that includes a time zone offset in its value. Data stored in the database is 
normalized to the database time zone (UTC) and time zone offset is not stored 
as part of the column data. When the data is retrieved, it to be returned in 
the user's local session time zone.

i.e:
{noformat}
CREATE TABLE timestamp(ts TIMESTAMP, t_tz TIMESTAMP WITH LOCAL TIME ZONE);
SET TIME ZONE 'tz1';
INSERT INTO timestamp VALUES ('2011-01-01 01:01:01', TIMESTAMP WITH LOCAL TIME 
ZONE '2011-01-01 01:01:01');
SET TIME ZONE 'tz2';
INSERT INTO timestamp VALUES ('2011-01-01 01:01:01', TIMESTAMP WITH LOCAL TIME 
ZONE '2011-01-01 01:01:01');
...
select * from timestamp;{noformat}
returned rows need to be different in case of different tz1 and tz2 offsets but 
they are equals for now. Also returned representation need to be present in 
user session time zone.


> Sql. Jdbc client.  Support TIMESTAMP WITH LOCAL TIME ZONE type
> --------------------------------------------------------------
>
>                 Key: IGNITE-19274
>                 URL: https://issues.apache.org/jira/browse/IGNITE-19274
>             Project: Ignite
>          Issue Type: Bug
>          Components: sql
>    Affects Versions: 3.0.0-beta1
>            Reporter: Evgeny Stanilovsky
>            Priority: Major
>              Labels: ignite-3
>
> The {{TIMESTAMP WITH LOCAL TIME ZONE}} data type is a variant of 
> {{TIMESTAMP}} that includes a time zone offset in its value. Data stored in 
> the database is normalized to the database time zone (UTC) and time zone 
> offset is not stored as part of the column data. When the data is retrieved, 
> it to be returned in the user's local session time zone.
> i.e:
> {noformat}
> CREATE TABLE timestamp(ts TIMESTAMP, t_tz TIMESTAMP WITH LOCAL TIME ZONE);
> SET TIME ZONE 'tz1';
> INSERT INTO timestamp VALUES ('2011-01-01 01:01:01', TIMESTAMP WITH LOCAL 
> TIME ZONE '2011-01-01 01:01:01');
> SET TIME ZONE 'tz2';
> INSERT INTO timestamp VALUES ('2011-01-01 01:01:01', TIMESTAMP WITH LOCAL 
> TIME ZONE '2011-01-01 01:01:01');
> ...
> select * from timestamp;{noformat}
> returned rows need to be different in case of different tz1 and tz2 offsets 
> but they are equals for now. Also returned representation need to be present 
> in user session time zone.
> h5. Update from 26.02.2024:
> Definition of done for this task:
> * Client time zone is passed to server (check other database implementations 
> to decide how and when to pass it).
> * Data of type "TIMESTAMP With LOCAL TIME ZONE" can be written/read correctly 
> using the dynamic parameter.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to