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
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
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 DTS rule, CET (Central European Time) is 1 hour
ahe
On 08-07-2020 20:16, Pavel Cisar wrote:
Mark,
I use iUtil
Dne 08. 07. 20 v 17:44 Mark Rotteveel napsal(a):
The thing is, TIME WITH TIME ZONE for named time zone should be
considered at 2020-01-01, so the relevant DST rule for that date is
in effect.
Says who? Why 2020-01-01 and not other
Mark,
I use iUtil
Dne 08. 07. 20 v 17:44 Mark Rotteveel napsal(a):
The thing is, TIME WITH TIME ZONE for named time zone should be
considered at 2020-01-01, so the relevant DST rule for that date is
in effect.
Says who? Why 2020-01-01 and not other date? Because Firebird uses it
does not m
On 08-07-2020 16:54, Pavel Cisar wrote:
Dne 08. 07. 20 v 15:32 Mark Rotteveel napsal(a):
The problem is how this is handled in Python standard library. It does
define only abstract base class for timezone handling
(https://docs.python.org/3.8/library/datetime.html#tzinfo-objects).
There are two i
On 08/07/2020 14:00, Pavel Cisar wrote:
TIME WITH TIMEZONE is pointless. It sort off works for "naive" TZ that
does not have things like summer time and other time shifts based on
date. The pytz library does not even allow you to create time with
such tz. The dateutil does, but the usability is
Dne 08. 07. 20 v 15:32 Mark Rotteveel napsal(a):
TIME WITH TIMEZONE is pointless. It sort off works for "naive" TZ
that does not have things like summer time and other time shifts
based on date. The pytz library does not even allow you to create
time with such tz. The dateutil does, but the u
On 08/07/2020 10:44, Dimitry Sibiryakov wrote:
> 08.07.2020 15:32, Adriano dos Santos Fernandes wrote:
>> I personally think TIME-TZ with regions are a valid thing (albeit weird
>> depending on the operations) because it fills a gap where one creates a
>> TIME and a additional region column. TIME-T
On 08/07/2020 14:44, Dimitry Sibiryakov wrote:
08.07.2020 15:32, Adriano dos Santos Fernandes wrote:
I personally think TIME-TZ with regions are a valid thing (albeit weird
depending on the operations) because it fills a gap where one creates a
TIME and a additional region column. TIME-TZ with o
08.07.2020 15:32, Adriano dos Santos Fernandes wrote:
I personally think TIME-TZ with regions are a valid thing (albeit weird
depending on the operations) because it fills a gap where one creates a
TIME and a additional region column. TIME-TZ with offsets only (no
regions) does not have the weird
On 08-07-2020 15:00, Pavel Cisar wrote:
I'm trying to implement support for FB 4 TIME/TIMESTAMP WITH TIMEZONE in
new Python driver, and I'm constantly hitting a stone wall with it.
The TZ support in standard datetime Python module is nice, smart and
flexible, but builtin support does not suppo
On 08/07/2020 10:00, Pavel Cisar wrote:
> Hi all,
>
> I'm trying to implement support for FB 4 TIME/TIMESTAMP WITH TIMEZONE
> in new Python driver, and I'm constantly hitting a stone wall with it.
>
> The TZ support in standard datetime Python module is nice, smart and
> flexible, but builtin suppo
Hi all,
I'm trying to implement support for FB 4 TIME/TIMESTAMP WITH TIMEZONE in
new Python driver, and I'm constantly hitting a stone wall with it.
The TZ support in standard datetime Python module is nice, smart and
flexible, but builtin support does not supports complex TZ with time
shift
25 matches
Mail list logo
