On 12/06/2019 10:18, Dimitry Sibiryakov wrote: > 12.06.2019 13:43, Adriano dos Santos Fernandes wrote: >> Then we will not have a single source of truth anymore. >> >> When user will create a client timestamp-tz value, he will need to fill >> that fields too, manually (with kill the current functionality) or >> automatically (making difficult what is currently simple and having the >> same "problems" you see now). > > Even if a user would like to create timestamp-tz value (which I > really doubt),
So we can remove the feature completely then. > it will be his problem. From our side it is enough to write a definite > rules of value's interpretation. > For example "if TZ ID is provided it is used, otherwise if > displacement provided it is used, otherwise value is considered to be > UTC". He can always use +00 directly a let people who install the client correctly do they work. > This worked for years for character fields and I don't see any > reason why it cannot work for timestamps. > What a complete misunderstood of things! First of all character sets are fixed per table/column. User can insert/update data with different character set, but in the end it doesn't matter, data is stored in the table/column character set. TZ data has the offset/region per table/column/record and actual offset/region matter a lot and should never be changed by the engine. Second, they do not have another dimension like TZ data does. Actual offset is calculated depending on the temporal value, which I believe I don't need to say what the range is and how that make the problems completely different than you pretend it to be. Third, intl data has architectural problems too, and the fact it's being worked around for 30 years does not remove then. A simple client (let's say ISQL) is incapable of do its simple form of work completely correct. It can't just listen for commands and display results correctly even having the connection charset (which supposedly is the necessary thing for it). Intl CHAR data does not have the byte length attached with data. Actual calculation of it is based on heuristics which is not always correct. Intl CHAR and VARCHAR data does not have the logical (character) length attached with data, so it can't format (pad) result. Older versions of ISQL was doing a terrible and bizarre job, which was fixed with incomplete heuristics that works only for UTF-8. The only marginal similarity of your assumption is that lasts two paragraphs, as the fix for them is also not what was proposed for timestamps, as the strings created by the user should not have that data filled be the user too. So for me it's clear we have a kind of problem that must be fixed in another way (something like a way to have output messages received by the client with additional data than the data that is present on they descriptors). Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
