On 2019-06-14 19:12, Lester Caine wrote:
On 14/06/2019 16:22, Mark Rotteveel wrote:
While implementing this feature in Jaybird I even considered using the
approach used by the PostgreSQL JDBC and that was simply always using
the UTC time and not even bothering with the offset and region
inform
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
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 ra
On 14/06/2019 16:22, Mark Rotteveel wrote:
While implementing this feature in Jaybird I even considered using the
approach used by the PostgreSQL JDBC and that was simply always using
the UTC time and not even bothering with the offset and region information.
PostgreSQL's built in timezone han
2019. 06. 14. 15:16 keltezéssel, Alex Peshkoff via Firebird-devel írta:
What do
ldd isql (in appropriate bin dirs)
and
ldd /usr/lib64/libfbclient.so
show in both cases?
With own build
/usr/local/firebird/bin$ ldd isql
linux-vdso.so.1 (0x7ffe53561000)
libfbclient.so.2 =>
On 14-6-2019 17:33, Dimitry Sibiryakov wrote:
14.06.2019 17:09, Mark Rotteveel wrote:
And that is not really workable if the client does want to use offset
based values and for example doesn't know the zone Firebird uses, or
if Firebird uses an offset that is too large.
It doesn't matter.
On 14-6-2019 15:45, Vlad Khorsun wrote:
14.06.2019 16:27, Adriano dos Santos Fernandes wrote:
So as everyone has they own names, Firebird has it too. And it also has
the IDs. So IDs and names are fixed in Firebird and to use ICU Firebird
maps these names to ICU names (a actual 1-1 as currently t
14.06.2019 17:09, Mark Rotteveel wrote:
And that is not really workable if the client does want to use offset based values and for
example doesn't know the zone Firebird uses, or if Firebird uses an offset that is too large.
It doesn't matter. In Vlad's suggestion server always sends to clien
On 14-6-2019 14:56, Vlad Khorsun wrote:
14.06.2019 14:58, Mark Rotteveel wrote:
I prefer the current approach where the time is communicated in UTC
with the offset or region information added for presentation purposes.
Having the time in UTC will always allow a fallback to at least a
usable va
On 14-6-2019 15:25, Vlad Khorsun wrote:
14.06.2019 16:17, Adriano dos Santos Fernandes wrote:
Do you even worked with a library doing datetime logic in a way suitable
for multiple time zones?
Every one stores the UTC time more the region _or_ offset. The
displayable value is calculated only whe
On 14/06/2019 14:27, Adriano dos Santos Fernandes wrote:
Note that ICU is a theoretical implementation detail, so Firebird has a
gateway for it also in the client to not reimplement it. But this is
important: at least currently, ICU is an implementation detail.
Currently if Firebird wants to imp
14.06.2019 16:27, Adriano dos Santos Fernandes wrote:
On 14/06/2019 09:56, Vlad Khorsun wrote:
Mapping between region_ID and regin_Name could be easily obtained
from server
(RDB$TIME_ZONES) if necessary. It could be done once per client
process lifetime.
Initial mapping could be hardcoded in
On 14/06/2019 10:25, Vlad Khorsun wrote:
>>>
>> Do you even worked with a library doing datetime logic in a way suitable
>> for multiple time zones?
>>
>> Every one stores the UTC time more the region _or_ offset. The
>> displayable value is calculated only when one wants to display the
>> value.
>
14.06.2019 15:17, Adriano dos Santos Fernandes wrote:
Every one stores the UTC time more the region_or_ offset.
Nobody is talking about *store* here.
The displayable value is calculated only when one wants to display the value.
Yes, and this is the moment when _server_ executes a query
On 14/06/2019 09:56, Vlad Khorsun wrote:
>
> Mapping between region_ID and regin_Name could be easily obtained
> from server
> (RDB$TIME_ZONES) if necessary. It could be done once per client
> process lifetime.
> Initial mapping could be hardcoded into Jaybird and updated when
> necessary.
> We c
14.06.2019 16:17, Adriano dos Santos Fernandes wrote:
On 13/06/2019 17:05, Vlad Khorsun wrote:
13.06.2019 16:44, Alex Peshkoff via Firebird-devel wrote:
On 13.06.2019 12:43, Vlad Khorsun wrote:
First, you loose things. The adjusted (displayable) timestamp is not
convertible back for duplicate
On 13/06/2019 17:05, Vlad Khorsun wrote:
> 13.06.2019 16:44, Alex Peshkoff via Firebird-devel wrote:
>> On 13.06.2019 12:43, Vlad Khorsun wrote:
>>
First, you loose things. The adjusted (displayable) timestamp is not
convertible back for duplicated timestamps (DST end).
>>>
>>> Not sure
On 14.06.2019 9:00, Gabor Boros wrote:
2019. 06. 13. 10:51 keltezéssel, Paul Beach írta:
a, is there a findable symlink from libfbclient.so.2 to the real name of
libfbclient (probably libfbclient.so.3.0.5)
b, is the installer creating it?
Output of "find / -name "libfbclient*" -type l -ls"
w
On 14.06.2019 12:37, Gabor Boros wrote:
2019. 06. 13. 10:51 keltezéssel, Paul Beach írta:
b, is the installer creating it?
I see some difference between the two install.sh files. The trivial
/opt/firebird vs /usr/local/firebird and two times "if [ "yes" = "yes"
]" vs "if [ "no" = "yes" ]".
14.06.2019 14:58, Mark Rotteveel wrote:
On 2019-06-13 22:12, Vlad Khorsun wrote:
13.06.2019 17:02, Adriano dos Santos Fernandes wrote:
On 13/06/2019 06:43, Vlad Khorsun wrote:
I don't offer to change internal representation (UTC +
offset\region_id) as is.
This is the only way to have corr
On 2019-06-13 22:05, Vlad Khorsun wrote:
13.06.2019 16:44, Alex Peshkoff via Firebird-devel wrote:
On 13.06.2019 12:43, Vlad Khorsun wrote:
First, you loose things. The adjusted (displayable) timestamp is not
convertible back for duplicated timestamps (DST end).
Not sure i got you. Could y
On 2019-06-13 22:12, Vlad Khorsun wrote:
13.06.2019 17:02, Adriano dos Santos Fernandes wrote:
On 13/06/2019 06:43, Vlad Khorsun wrote:
I don't offer to change internal representation (UTC +
offset\region_id) as is.
This is the only way to have correct comparison of timestamp with
time
z
2019. 06. 13. 10:51 keltezéssel, Paul Beach írta:
b, is the installer creating it?
I see some difference between the two install.sh files. The trivial
/opt/firebird vs /usr/local/firebird and two times "if [ "yes" = "yes"
]" vs "if [ "no" = "yes" ]". What is this "if" thing? I hope it's a jo
23 matches
Mail list logo
