Adriano,
Dne 09. 07. 20 v 17:32 Adriano dos Santos Fernandes napsal(a):
I prefer to base implementations on standard + competitors + common sense.
So far from the standard pieces, Firebird follow standard.
From the extensions pieces, Firebird follow competitor who implement
same extensions,
On 09/07/2020 12:23, Pavel Cisar wrote:
> Adriano,
>
> Dne 09. 07. 20 v 16:39 Adriano dos Santos Fernandes napsal(a):
>>
>> Storage apart, it still requires conversions to TIMESTAMP, comparations,
>> etc work, so a base date is anyway required.
>
> Conversion to TIMESTAMP without providing the exac
Adriano,
Dne 09. 07. 20 v 16:39 Adriano dos Santos Fernandes napsal(a):
Storage apart, it still requires conversions to TIMESTAMP, comparations,
etc work, so a base date is anyway required.
Conversion to TIMESTAMP without providing the exact date explicitly is
meaningless (as anomalies are n
Dne 09. 07. 20 v 15:54 Adriano dos Santos Fernandes napsal(a):
If OS is configured with deprecated time zone, it will return deprecated
time zone name.
I don't have my system configured to use deprecated time zone name. My
/etc/localtime is a symlink to /usr/share/zoneinfo/Europe/Prague
B
On 09/07/2020 11:30, Pavel Cisar wrote:
> Mark,
>
> Dne 09. 07. 20 v 13:47 Mark Rotteveel napsal(a):
>>
>>>
>>> Again, it's not correct, it's just consistent/invariant across
>>> calendar.
>>
>> Please explain exactly which aspects are not correct according to
>> you. If the goal is to produce a co
Engine may hang due to races when starting crypt thread and simultaneous
shutdown
-
Key: CORE-6360
URL: http://tracker.firebirdsql.org/browse/CORE-6360
Project: Firebird
Mark,
Dne 09. 07. 20 v 13:47 Mark Rotteveel napsal(a):
Again, it's not correct, it's just consistent/invariant across calendar.
Please explain exactly which aspects are not correct according to you.
If the goal is to produce a consistent value at a named zone, this is
the only way to do i
If OS is configured with deprecated time zone, it will return deprecated
time zone name.
Europe/Prague is there in Linux.
$ ll /usr/share/zoneinfo/Europe/Prague -rw-r--r-- 1 root root 2329 May 7
18:04 /usr/share/zoneinfo/Europe/Prague $ lsb_release -a No LSB modules
are available. Distributor ID:
Adriano,
Obviously the problem is in impedance mismatch between ICU and other
systems that use IANA timezone database (notably POSIX, can't speak for
Windows). This is then moved to programming languages that typically use
OS services to handle timezone information, and not ICU (which is just
On 09/07/2020 08:40, Pavel Cisar wrote:
Dne 08. 07. 20 v 21:13 Mark Rotteveel napsal(a):
On 08-07-2020 20:16, Pavel Cisar wrote:
As I said, CET is a zone that has a DST rule, that means that - for
example - on 2020-01-01, 12:30 CET is 11:30 UTC, while at 2020-06-02,
12:30 CET (== 12:30 CEST
On 2020-07-09 09:10, Pavel Cisar wrote:
MArk,
Dne 08. 07. 20 v 20:51 Mark Rotteveel napsal(a):
Says who? Why 2020-01-01 and not other date? Because Firebird uses it
does not make it right, it just make it consistent with Firebird.
Also
mind that DTS is just one from possible time shifts for
On 09/07/2020 04:40, Pavel Cisar wrote:
>
> Please, read some documentation about the problem in general, not only
> documentation for libraries you (or Firebird) use to get unbiased view.
>
Given the history of Python (2.7 vs 3) I would think it's quite the
contrary, you should point why Python is
Dne 08. 07. 20 v 21:13 Mark Rotteveel napsal(a):
On 08-07-2020 20:16, Pavel Cisar wrote:
As I said, CET is a zone that has a DST rule, that means that - for
example - on 2020-01-01, 12:30 CET is 11:30 UTC, while at 2020-06-02,
12:30 CET (== 12:30 CEST) is 10:30 UTC.
CET is NOT a zone with
MArk,
Dne 08. 07. 20 v 20:51 Mark Rotteveel napsal(a):
Says who? Why 2020-01-01 and not other date? Because Firebird uses it
does not make it right, it just make it consistent with Firebird. Also
mind that DTS is just one from possible time shifts for timezone.
Yes, Firebird says so. Firebird
14 matches
Mail list logo
