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 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. >
Agreed. >>>> 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. > Ok. > 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, before implementation, if nobody implemented it, it would now be on one of two extremes: silent or that b*t, does not work in another calendar, does not work outside earth, does not work in my application if I do not change it... But really test the implemented version, nobody does... Adriano ------------------------------------------------------------------------------ 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
