On 5-6-2018 11:43, Lester Caine wrote:
On 05/06/18 09:39, Mark Rotteveel wrote:
On 5-6-2018 10:16, Lester Caine wrote:
On 05/06/18 08:50, Mark Rotteveel wrote:
That naming doesn't make much sense to me, and I actually found the
RULE_START and RULE_END naming pretty clear and self-explanatory.
Except that it's not the rule itself, but the transitions within the
rule ... I'd still like to know why there is a need for the 'end'
anyway as the next transition already contains that.
Because that is easier when doing queries... select * from ... where
current_timestamp between rule_start and rule_end.
But you have to use 'current_timestamp' to find the 'rule_start' and
'rule_end' and for many timezones 'rule_end' will simply be the current
generic end date returned by the tz database. It requires a little bit
more processing than simply pulling out two numbers for a single
transition. You normally need the data from the next transition in any
case. Your example would be much better as
select * from ... where date between tzoffset(tz, date, current_start)
and tzoffset(tz, date, next_start)
And we can also have tzoffset(tz, date, current) and tzoffset(tz, date,
next )
That is still no argument to leave the end of the range out of the
provided information. Including it will have little to no cost, and
provides full information in one record, which makes it self-contained
and easy to understand.
And I've still not had anybody explain why the removal of seconds
from the offsets is seen as a good idea?
Why is it a bad idea?
Because the first transition of every rule set is from LMT to a standard
time of some sort. All normalizations to UTC time prior to various times
in the last 200 years involve a seconds based correction. SO if one is
doing any historic work, one has to ditch many current methods ...
because they only work from 1970 ... and do things a different way. At
the very least, the documentation has to SAY when the built in
procedures can be relied on, and when one has to ditch them. At the same
time adding the fact the dates are all Gregorian would be useful.
Knowing that historic changes TO Gregorian dates need special treatment
would be useful ... I only learnt that Russia was still on the Julian
calendar until the early 1900's this week ...
Is there any reason why post-1970 time zones need second resolution for
zone offsets? Or is there any other strong argument why second precision
is needed?
To be honest, I don't see why we should cater to an extremely uncommon
minor use-case which will likely be of no interests to the majority of
Firebird users, and that will be fraught with so many complications that
you'll probably need your own solution anyway if you need full precision
offsets pre-1970s. The TZ database does not guarantee correctness nor
completeness of its information before 1970, so using second precision
there will probably only lead to a false sense of precision.
Be aware that I'm not asking and arguing this because I hate the idea of
using seconds, but changing this has more impact than just the
information reported here.
Given the choice in the current implementation to encode both time zone
identifiers or offset information in 2 bytes, it doesn't have any room
for an offset in seconds. So supporting an offset in seconds will have
profound impact on not just the information reported here, but on the
actual API implementation, storage, etc. And if we don't change it
there, then there is also no need to report a precision in seconds
anyway, because it wouldn't match with the precision of the API.
Maybe it is just me, but it seems we are now having discussions that
should have been had and resolved before implementation.
And I repeat again, that I think that this feature should not land in
Firebird 4, and needs to be delayed to Firebird 5.
Mark
--
Mark Rotteveel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
