Re: [Firebird-devel] Support for timed-zones datatypes

On 21/11/17 18:31, Mark Rotteveel wrote: > On 2017-11-21 18:31, Lester Caine wrote: >> On 21/11/17 16:42, Mark Rotteveel wrote: >>> >>> If you need that, you also need to store the actual timezone somewhere. >>> PostgreSQL for example also uses an offset for timestamp with timezone >>> (not sure

Re: [Firebird-devel] Support for timed-zones datatypes

On 2017-11-21 18:31, Lester Caine wrote: On 21/11/17 16:42, Mark Rotteveel wrote: If you need that, you also need to store the actual timezone somewhere. PostgreSQL for example also uses an offset for timestamp with timezone (not sure if that is required by SQL standard though). Firebird

Re: [Firebird-devel] Support for timed-zones datatypes

21.11.2017 19:45, Adriano dos Santos Fernandes wrote: If CURRENT_TIMEZONE returns TIMESTAMP WITH TIME ZONE, it will be described with the new datatype and will broke all applications that rely on isc_dsql_describe. True. I was thinking about "static" applications, sorry. Then the

Re: [Firebird-devel] Support for timed-zones datatypes

On 2017-11-21 17:49, Adriano dos Santos Fernandes wrote: On 21/11/2017 14:16, Lester Caine wrote: On 21/11/17 14:55, Adriano dos Santos Fernandes wrote: Implementing TIME WITH TIME ZONE and TIMESTAMP WITH TIME ZONE datatypes as specified in the SQL standard is not a big problem. The only

Re: [Firebird-devel] Support for timed-zones datatypes

On 2017-11-21 17:52, Adriano dos Santos Fernandes wrote: On 21/11/2017 14:42, Mark Rotteveel wrote: If you need that, you also need to store the actual timezone somewhere. PostgreSQL for example also uses an offset for timestamp with timezone (not sure if that is required by SQL standard

Re: [Firebird-devel] Support for timed-zones datatypes

On 21/11/17 16:42, Mark Rotteveel wrote: > > If you need that, you also need to store the actual timezone somewhere. > PostgreSQL for example also uses an offset for timestamp with timezone > (not sure if that is required by SQL standard though). Firebird currently works nicely simply because

Re: [Firebird-devel] Support for timed-zones datatypes

On 21/11/2017 14:42, Mark Rotteveel wrote: > > If you need that, you also need to store the actual timezone > somewhere. PostgreSQL for example also uses an offset for timestamp > with timezone (not sure if that is required by SQL standard though). > Each "TIMESTAMP-TZ" has a hour/minute offset

Re: [Firebird-devel] Support for timed-zones datatypes

On 21/11/2017 14:16, Lester Caine wrote: > On 21/11/17 14:55, Adriano dos Santos Fernandes wrote: >> Implementing TIME WITH TIME ZONE and TIMESTAMP WITH TIME ZONE datatypes >> as specified in the SQL standard is not a big problem. > The only question is just how is the timezone data managed. It is

Re: [Firebird-devel] Support for timed-zones datatypes

On 21/11/2017 13:56, Dmitry Yemanov wrote: > 21.11.2017 17:55, Adriano dos Santos Fernandes wrote: >> >> Implementing TIME WITH TIME ZONE and TIMESTAMP WITH TIME ZONE datatypes >> as specified in the SQL standard is not a big problem. >> >> However, standard says that CURRENT_TIME /

Re: [Firebird-devel] Support for timed-zones datatypes

On 2017-11-21 16:56, Dmitry Yemanov wrote: 21.11.2017 17:55, Adriano dos Santos Fernandes wrote: Implementing TIME WITH TIME ZONE and TIMESTAMP WITH TIME ZONE datatypes as specified in the SQL standard is not a big problem. However, standard says that CURRENT_TIME / CURRENT_TIMESTAMP

Re: [Firebird-devel] Support for timed-zones datatypes

On 2017-11-21 17:16, Lester Caine wrote: On 21/11/17 14:55, Adriano dos Santos Fernandes wrote: Implementing TIME WITH TIME ZONE and TIMESTAMP WITH TIME ZONE datatypes as specified in the SQL standard is not a big problem. The only question is just how is the timezone data managed. It is

Re: [Firebird-devel] Support for timed-zones datatypes

On 21/11/17 14:55, Adriano dos Santos Fernandes wrote: > Implementing TIME WITH TIME ZONE and TIMESTAMP WITH TIME ZONE datatypes > as specified in the SQL standard is not a big problem. The only question is just how is the timezone data managed. It is useless simply having an offset value when

Re: [Firebird-devel] Support for timed-zones datatypes

21.11.2017 18:56, Dmitry Yemanov wrote: So only conversion to string seems to be a real problem. And IMHO we could live with that. And given that we speak about PSQL (accessible for modifications), people may replace CURRENT_TIME with LOCALTIME to preserve the string conversion results, if

Re: [Firebird-devel] Support for timed-zones datatypes

21.11.2017 17:55, Adriano dos Santos Fernandes wrote: Implementing TIME WITH TIME ZONE and TIMESTAMP WITH TIME ZONE datatypes as specified in the SQL standard is not a big problem. However, standard says that CURRENT_TIME / CURRENT_TIMESTAMP returns the timed-zone datatype. That causes two

Re: [Firebird-devel] Support for timed-zones datatypes

On 2017-11-21 15:55, Adriano dos Santos Fernandes wrote: Hi! Implementing TIME WITH TIME ZONE and TIMESTAMP WITH TIME ZONE datatypes as specified in the SQL standard is not a big problem. However, standard says that CURRENT_TIME / CURRENT_TIMESTAMP returns the timed-zone datatype. That

[Firebird-devel] Support for timed-zones datatypes

Hi! Implementing TIME WITH TIME ZONE and TIMESTAMP WITH TIME ZONE datatypes as specified in the SQL standard is not a big problem. However, standard says that CURRENT_TIME / CURRENT_TIMESTAMP returns the timed-zone datatype. That causes two problems: - Internally (say in PSQL), conversion to

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5665) Inconsistency of formatting double precision values between linux and windows

This same problem is also present in version 2.5.7 I just checked Best Regards -- Ismael - Original Message - From: "Artyom Smirnov (JIRA)" To: Sent: Monday, November 20, 2017 8:19 AM Subject: [Firebird-devel]