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) is 10:30 UTC.
CET is NOT a zone with DTS rule, CET (Central European Time) is 1
hour ahead of Coordinated Universal Time (UTC). This time zone is in
use during standard time in: Europe, Africa. Some places observe
daylight saving time/summer time during the summer, and therefore use
CEST (Central European Summer Time) in the summer. So, timezones like
'Europe/Prague' HAVE DST rules where they switch between CET and CEST.
For example Algeria and Tunisia have CET the whole year as they don't
switch to CEST.
And that is yet another reason not to use the short time zone ids,
because they are ambiguous, the ICU time zone database does apply DST
rules to CET:
How ICU can apply DTS rules on CET? CET has NO DTS rules, only named
zones (countries) can. CET is simply time that is UTC+01:00, period. So
if ICU (and through it Firebird) defines DTS for CET, it's plain wrong.
If it wouled be true and CET would have DTS rules, Algeria and Tunisia
couldn't have it for WHOLE YEAR!
However, the impression that CET has DTS rules could happen when library
or system does use the same name for DTS shifts, i.e. uses only CET and
does not recognize CET/CEST. In such case the UTC offset may differ
while the name is the same. Other systems use different names to signal
that offset differs (because DTS is actually a seasonal shift to another
timezone). Both approaches (single name, different offset + distinct
names for offsets) are widely used and acceptable. The single name +
different offset approach is actually NEWER than multi-name and is still
not the dominant or most significant. For example the POSIX systems
(i.e. Linux) today use the multiname approach (and they also use the
IANA timezone database).
Please, read some documentation about the problem in general, not only
documentation for libraries you (or Firebird) use to get unbiased view.
And yes, it's a mess, but we don't live in ideal world.
Much of this goes back to the bodge that browsers use in only providing
a clients offset. Finally getting around to fixing that particular bug
would go a long way to making things work better. NEEDING to have
clients log into a services in order that you can establish their
correct DST rules has been essential for many years. This is why I
prefer to currently manage local times based on an independent field
identifying the correct local location.
--
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
