On 3-4-2019 17:03, Roman Simakov wrote:
чт, 3 янв. 2019 г. в 14:15, Adriano dos Santos Fernandes :
On 30/12/2018 07:22, Mark Rotteveel wrote:
The error is now:
"""
RAMONASun Dec 30 09:59:28 2018
ICU error (0) retrieving the system time zone (W. Europe Standard
Time). Falling back
чт, 3 янв. 2019 г. в 14:15, Adriano dos Santos Fernandes :
>
> On 30/12/2018 07:22, Mark Rotteveel wrote:
> >
> > The error is now:
> >
> > """
> > RAMONASun Dec 30 09:59:28 2018
> > ICU error (0) retrieving the system time zone (W. Europe Standard
> > Time). Falling back to displacement.
On 30/12/2018 07:22, Mark Rotteveel wrote:
>
> The error is now:
>
> """
> RAMONA Sun Dec 30 09:59:28 2018
> ICU error (0) retrieving the system time zone (W. Europe Standard
> Time). Falling back to displacement.
> """
>
That's because Windows build is still with old ICU without time zone
29.12.2018 11:10, Adriano dos Santos Fernandes wrote:
The cached in request value is now the timestamp with tz, then localtimestamp requires a
conversion.
If request requested timestamp without tz, why it caches it with tz?
That conversion requires to open ICU calendar to get the effective
On 29/12/2018 10:10, Adriano dos Santos Fernandes wrote:
The cached in request value is now the timestamp with tz, then
localtimestamp requires a conversion.
That conversion requires to open ICU calendar to get the effective
displacement.
Please try to alter the session time zone to a
On Sat, Dec 29, 2018, 07:17 Mark Rotteveel I was doing an artificial performance test on Firebird by inserting into
> a table that had a column
>
> updatedts timestamp default localtimestamp
>
> The insert did not touch this column (so the default is applied). To my
> surprise, that was about 7 -
I was doing an artificial performance test on Firebird by inserting into
a table that had a column
updatedts timestamp default localtimestamp
The insert did not touch this column (so the default is applied). To my
surprise, that was about 7 - 10 % slower than using CURRENT_TIMESTAMP:
