On 3-7-2019 15:27, Vlad Khorsun wrote:
14.06.2019 22:10, Mark Rotteveel wrote:
On 2019-06-14 20:27, Adriano dos Santos Fernandes wrote:
On 14/06/2019 13:01, Mark Rotteveel wrote:
And I repeat what I said earlier: if Firebird uses an offset that is
too large then I can't use the standard features in Java for date/time
handling and I'll need to mangle things myself to get a - hopefully -
meaningful value.
What is the Java range?
[-18:00, +18:00], see
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/ZoneOffset.html
:
This article shows that Java keep seconds in ZoneOffset (not minutes
as Firebird currently).
18 hours limit is probably because two-byte word could keep just 18 full
hour's:
>
65535 / (60*60) = 18
>
> but sign should be kept somewhere else...
No, Java's `ZoneOffset` uses an `int` (which is 32 bit signed). The
reason for the offset is documented on the link:
"""
In 2008, time-zone offsets around the world extended from -12:00 to
+14:00. To prevent any problems with that range being extended, yet
still provide validation, the range of offsets is restricted to -18:00
to 18:00 inclusive.
"""
In other words: restrict it to reasonable values, but keep room for
potential offsets changes outside the current offsets in use.
Should we reconsider current implementation ?
Unless someone comes up with a complete proposal for discussion (and not
an email thread with dozens of conflicting opinions), then I suggest we
keep the implementation as is.
I'll repeat my position:
1. The minimal thing that can and should be done to address the problem
that kicked off this email thread, is to ensure that `decodeTimestampTz`
has a fallback if ICU is not available to render named zones properly
(that is: render the time as UTC or +00:00 which is 1) possible with the
current information available and 2) an acceptable fallback).
2. Changing how WITH TIME ZONE types fundamentally work in the protocol
this late in the development cycle is in my opinion problematic, and the
alternatives suggested up to this point are - in my opinion - not better
and in some cases worse.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
