Re: [Firebird-devel] RDB$TIME_ZONE_UTIL package

2018-06-05 Thread Lester Caine
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

Re: [Firebird-devel] RDB$TIME_ZONE_UTIL package

2018-06-05 Thread Lester Caine
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,

Re: [Firebird-devel] RDB$TIME_ZONE_UTIL package

2018-06-05 Thread Adriano dos Santos Fernandes
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

Re: [Firebird-devel] RDB$TIME_ZONE_UTIL package

2018-06-05 Thread Adriano dos Santos Fernandes
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

Re: [Firebird-devel] RDB$TIME_ZONE_UTIL package

2018-06-05 Thread Adriano dos Santos Fernandes
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

Re: [Firebird-devel] RDB$TIME_ZONE_UTIL package

2018-06-05 Thread Adriano dos Santos Fernandes
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

Re: [Firebird-devel] RDB$TIME_ZONE_UTIL package

2018-06-05 Thread Mark Rotteveel
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.

Re: [Firebird-devel] RDB$TIME_ZONE_UTIL package

2018-06-05 Thread Lester Caine
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,

Re: [Firebird-devel] RDB$TIME_ZONE_UTIL package

2018-06-05 Thread Mark Rotteveel
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 ...

Re: [Firebird-devel] RDB$TIME_ZONE_UTIL package

2018-06-05 Thread Lester Caine
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

Re: [Firebird-devel] RDB$TIME_ZONE_UTIL package

2018-06-05 Thread Mark Rotteveel
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