11.03.2020 19:08, Tony Whyman wrote:
The definitive document from Microsoft is here:
https://docs.microsoft.com/en-us/windows/win32/intl/international-components-for-unicode--icu-
It looks like the icu dlls are only available from Version 1709 onwards.
Interestingly, they are called:
On 10/03/2020 10:34, Dimitry Sibiryakov wrote:
10.03.2020 09:48, Alex Peshkoff via Firebird-devel wrote:
May be for old windows versions - yes, some problems. All the others
upgrade ICU as a part of regular OS upgrade. I.e. if one already has
local ICU extended format is definitely useless
On Tue, 10 Mar 2020 11:34:40 +0100
Dimitry Sibiryakov wrote:
> 10.03.2020 09:48, Alex Peshkoff via Firebird-devel wrote:
> > May be for old windows versions - yes, some problems. All the others
> > upgrade ICU as a part > of regular OS upgrade. I.e. if one already has
> > local ICU extended
On 2020-03-09 16:12, Adriano dos Santos Fernandes wrote:
On 08/03/2020 06:24, Mark Rotteveel wrote:
Please enlighten me in what way will I have "misunderstood the thing
completely", and will "Jaybird users [..] have a very wrong behavior
forever"?
That I talked in almost every message here
On 2020-03-09 17:48, Tony Whyman wrote:
My reading is that when the server's ICU is used, TIMESTAMP/TIME with
TIME ZONE values are returned as UTC with both the time zone id and
the time zone offset as computed by the server's ICU taking into
account any daylight savings time variations.
I
On 2020-03-09 16:04, Adriano dos Santos Fernandes wrote:
On 08/03/2020 06:24, Mark Rotteveel wrote:
On 05-03-2020 17:14, Adriano dos Santos Fernandes wrote:
The JDBC specification doesn't support named time zones, only offset
time zones
(OffsetDateTime/OffsetTime),
Please point me to that
10.03.2020 09:48, Alex Peshkoff via Firebird-devel wrote:
May be for old windows versions - yes, some problems. All the others upgrade ICU as a part
of regular OS upgrade. I.e. if one already has local ICU extended format is definitely
useless overhead.
ICU appeared only in recent builds of
Tony (& others),
On 2020-03-09 19:48, Tony Whyman wrote:
The question then arises as to why this is not the normal way of
working? Using the client's local ICU introduces a maintenance headache.
This argument I personally hardly accept. May be for old windows
versions - yes, some
On 04/03/2020 17:16, Alex Peshkoff via Firebird-devel wrote:
On 2020-03-04 20:01, Mark Rotteveel wrote:
What is the purpose of introducing yet another datatype called
EXTENDED TIME/TIMESTAMP WITH TIME ZONE?
Help users missing ICU on the client work with time zones.
I am still trying to
On 08/03/2020 06:24, Mark Rotteveel wrote:
>
> Please enlighten me in what way will I have "misunderstood the thing
> completely", and will "Jaybird users [..] have a very wrong behavior
> forever"?
>
That I talked in almost every message here in this list about the topic.
If you (driver and
On 08/03/2020 06:24, Mark Rotteveel wrote:
> On 05-03-2020 17:14, Adriano dos Santos Fernandes wrote:
> The JDBC specification doesn't support named time zones, only offset time
> zones
> (OffsetDateTime/OffsetTime),
Please point me to that text.
so I must convert to an offset-based data
>
On 05-03-2020 17:14, Adriano dos Santos Fernandes wrote:
Mark, I hope you never release a Jaybird version that converts named
regions to offsets in Java, because if you do you misunderstood the
thing completely and Jaybird users will need to have a very wrong
behavior forever.
Jaybird will
> In any case, we seem to have a stalemate here, so I guess there is not
> much point in continuing to argue. I'll grudgingly implement support in
> Jaybird by handling it identical to a normal TIMESTAMP WITH TIME ZONE,
> just in case someone configures a bind to EXTENDED TIME(STAMP) WITH TIME
On 06/03/2020 09:43, Mark Rotteveel wrote:
But that explanation primarily seems to boil down to that Adriano didn't
like it and that you didn't want to discuss it any further.
In any case, we seem to have a stalemate here, so I guess there is not
much point in continuing to argue. I'll
06.03.2020 14:03, Tony Whyman wrote:
This is all post Beta 1 stuff. When will there be a Beta 2 release
incorporating EXTENDED TIME(STAMP) WITH TIME ZONE?
When we finalize all the bits and pieces. This discussion should surely
happen before the feature is released to public.
Dmitry
This is all post Beta 1 stuff. When will there be a Beta 2 release
incorporating EXTENDED TIME(STAMP) WITH TIME ZONE?
On 06/03/2020 09:48, Alex Peshkoff via Firebird-devel wrote:
On 2020-03-06 12:43, Mark Rotteveel wrote:
I'll grudgingly implement support in Jaybird by handling it identical
On 2020-03-06 12:43, Mark Rotteveel wrote:
I'll grudgingly implement support in Jaybird by handling it identical
to a normal TIMESTAMP WITH TIME ZONE, just in case someone configures
a bind to EXTENDED TIME(STAMP) WITH TIME ZONE.
Absolutely right solution.
Firebird-Devel mailing list,
On 2020-03-06 07:59, Alex Peshkoff via Firebird-devel wrote:
On 2020-03-05 17:49, Mark Rotteveel wrote:
I see general benefits of communicating the actual offset always, see
also below. And I don't think it is a good idea to add a new datatype
which can have meaningful uses, only to remove it
On 2020-03-05 17:49, Mark Rotteveel wrote:
I see general benefits of communicating the actual offset always, see
also below. And I don't think it is a good idea to add a new datatype
which can have meaningful uses, only to remove it again at a later
time. That will surely break applications
Mark, I hope you never release a Jaybird version that converts named
regions to offsets in Java, because if you do you misunderstood the thing
completely and Jaybird users will need to have a very wrong behavior
forever.
Adriano
Em qui, 5 de mar de 2020 11:50, Mark Rotteveel
escreveu:
> On
On 2020-03-05 11:48, Alex Peshkoff via Firebird-devel wrote:
On 2020-03-04 20:35, Mark Rotteveel wrote:
On 04-03-2020 18:16, Alex Peshkoff via Firebird-devel wrote:
No. Use of them is very restricted - the _ONLY_ place where they can
be used in SQL is SET BIND statement.
I had missed that,
On 2020-03-04 20:35, Mark Rotteveel wrote:
On 04-03-2020 18:16, Alex Peshkoff via Firebird-devel wrote:
On 2020-03-04 20:01, Mark Rotteveel wrote:
What is the purpose of introducing yet another datatype called
EXTENDED TIME/TIMESTAMP WITH TIME ZONE?
Help users missing ICU on the client
On 04-03-2020 18:16, Alex Peshkoff via Firebird-devel wrote:
On 2020-03-04 20:01, Mark Rotteveel wrote:
What is the purpose of introducing yet another datatype called
EXTENDED TIME/TIMESTAMP WITH TIME ZONE?
Help users missing ICU on the client work with time zones.
I think this is
On 2020-03-04 20:01, Mark Rotteveel wrote:
What is the purpose of introducing yet another datatype called
EXTENDED TIME/TIMESTAMP WITH TIME ZONE?
Help users missing ICU on the client work with time zones.
I think this is extremely confusing, making both SQL
No. Use of them is very
What is the purpose of introducing yet another datatype called EXTENDED
TIME/TIMESTAMP WITH TIME ZONE?
I think this is extremely confusing, making both SQL and the wire
protocol more convoluted.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
26 matches
Mail list logo
