11.05.2018 18:31, Adriano dos Santos Fernandes wrote:
Here is the first README version for the time zone feature.
In decode/encode functions what fractions are used? Is it Firebird legacy fractions in
1/1 of a second or standard fractions in 1/10 of a second?
I see no mention
On 12/05/18 07:43, Mark Rotteveel wrote:
Like Macau, a lot of historic data has been added and for databases
handling historic material it would be nice if there was a way to have
matching correct offsets? Or we ignore the builtd in tools and
cintinue to rely on external functions ...
To be
On 12/05/2018 05:51, Dimitry Sibiryakov wrote:
> 11.05.2018 18:31, Adriano dos Santos Fernandes wrote:
>> Here is the first README version for the time zone feature.
>
> In decode/encode functions what fractions are used? Is it Firebird
> legacy fractions in 1/1 of a second or standard fract
On 12/05/2018 06:02, Lester Caine wrote:
>
> In part I can accept that, but short cuts need to be documented? It is
> not common knowledge that TZ data IS questionable prior to 1970, and
> with the amount of research being done on even just the second world
> war, knowing that time one is normali
12.05.2018 16:24, Adriano dos Santos Fernandes wrote:
In decode/encode functions what fractions are used? Is it Firebird
legacy fractions in 1/1 of a second or standard fractions in
1/10 of a second?
Same as with the WITHOUT tz types.
Isn't it better to support a standard nin
On 12/05/18 15:28, Adriano dos Santos Fernandes wrote:
The discussion is going to a place that the next part will be about time
zones as we know not works outside of Earth.
The current offering is not practical in a number of current real world
applications! And the same is true of other datab
