On 5-6-2018 18:10, Lester Caine wrote:
I do not recall seeing any discussion on the ground rules for handling
timezone offsets prior to an implementation being proposed? It could
then have been pointed out that the SQL rules simply don't work in a lot
of cases. The idea of listing the end time assumes that there will only
ever be 4 decimal places of second accuracy, but the involves cropping
current time systems. Avoiding the problem makes a lot more sense.
Firebird timestamps have a precision of 100 microseconds. No more, no
less, so 4 decimals precision is correct there. This clearly defines the
boundaries as [start, end]. You have a transition that starts at time x,
this means that the previous transition end (inclusive) is at the
previous tick (100 microseconds before time x).
So you get
1. [start_1, end_1] (where end_1 = start_1 - 1 tick (100 microseconds))
2. [start_2, end_2]
...
BTW: earlier you complained about it being fractional, and now you're
complaining about the precision of those fractions not being precise
enough?
I don't think I understand what you're arguing for and what the problem
is, unless you are arguing that the range end should be exclusive, so
[start, end), which means that "end" is the same value as "start" of the
next one, eg
1. [start_1, start_2)
2. [start_2, start_3)
...
Which might seem nice from a theory perspective, but does not play nice
with for example usage of BETWEEN.
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
