06.07.2019 12:16, Mark Rotteveel wrote:
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.
It doesn't explain why 18 hours is reasonable and 19 (or 17) is not.
But you missed more important point.
Should we reconsider current implementation ?
I speak about seconds in Java ZoneOffset type. How do you going to store
in Firebird database timestamps like '01.01.2020 12:34:56 +07:08:09' ?
Regards,
Vlad
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
