On 06/06/18 15:12, Adriano dos Santos Fernandes wrote:
I understand that is a bit weird to have the end data defined to the
. seconds, but it's the max. Firebird precision. If precision
increases, it would be increased too, of course.
That is part of the point. It is only valid within Fireb
On 06/06/18 13:12, Mark Rotteveel wrote:
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 t
On 06/06/2018 05:07, Jiří Činčura wrote:
>> 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.
> Could it be
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
On 06/06/18 09:07, Jiří Činčura wrote:
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.
Could it be that the data w
> 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.
Could it be that the data will be stored without "end" co
On 05/06/18 11:34, Mark Rotteveel wrote:
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
On 05/06/18 16:27, Adriano dos Santos Fernandes wrote:
Maybe it is just me, but it seems we are now having discussions that
should have been had and resolved before implementation.
In my whole life, I only see things being done when someone *really
does* it.
That discussion you were talking, b
On 05/06/2018 07:34, Mark Rotteveel wrote:
>
> Maybe it is just me, but it seems we are now having discussions that
> should have been had and resolved before implementation.
>
You, as a waterfall methodology advocate, can pretend it's not
implemented, so let's say we're still building the 1000 pag
On 05/06/2018 07:34, Mark Rotteveel wrote:
> 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 RU
On 05/06/2018 05:16, Lester Caine wrote:
>
>
> And I've still not had anybody explain why the removal of seconds from
> the offsets is seen as a good idea?
It's not present in the SQL standard.
Never see it being used in real world too.
Adriano
On 05/06/2018 04:50, Mark Rotteveel wrote:
> On 4-6-2018 17:17, Adriano dos Santos Fernandes wrote:
>> Procedure name TRANSITION_RULES is renamed to TRANSITIONS. Rules are
>> another thing, it's how the transitions are specified in the tzdb. It
>> may be added at another time.
>>
>> Output columns
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.
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,
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
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 nee
On 4-6-2018 17:17, Adriano dos Santos Fernandes wrote:
Procedure name TRANSITION_RULES is renamed to TRANSITIONS. Rules are
another thing, it's how the transitions are specified in the tzdb. It
may be added at another time.
Output columns RULE_START and RULE_END is renamed to INITIAL_TIMESTAMP
a
> Output columns RULE_START and RULE_END is renamed to
> INITIAL_TIMESTAMP and FINAL_TIMESTAMP.
START_TIMESTAMP and END_TIMESTAMP would be better (language wize)
DEFINITION_START/DEFINITION_END (or EFFECTIVE_FROM/EFFECTIVE_TO) would be even
better (the fact that the values are TIMESTAMPs does
On 03/06/2018 05:32, Mark Rotteveel wrote:
>
>> Function DATABASE_VERSION
>>
>> ---
>> SQL> select rdb$time_zone_util.database_version() from rdb$database;
>>
>> DATABASE_VERSION
>>
>> 2017c
>> ---
>
> Minor nitpick: the current db is 2018e.
>
The one present in Ub
On 30/05/18 01:45, Adriano dos Santos Fernandes wrote:
RULE_START 2019-10-20 03:00:00. GMT
RULE_END 2020-02-16 01:59:59. GMT
ZONE_OFFSET -180
DST_OFFSET 60
---
It list all transition rules from the start to the end date, including
the pre-start and post-end in the same r
On 30-5-2018 02:45, Adriano dos Santos Fernandes wrote:
Hi!
Here is first prototype of a system package, which worth discuss.
I have put the RDB$ prefix on the package name, as liking very much or
not, is the system prefix of Firebird objects.
I did not named its sub routines or they parameter
Hi!
Here is first prototype of a system package, which worth discuss.
I have put the RDB$ prefix on the package name, as liking very much or
not, is the system prefix of Firebird objects.
I did not named its sub routines or they parameters with RDB$ prefix.
That's totally annoying and unnecessar
22 matches
Mail list logo
