On 05.09.2019 12:04, Lester Caine wrote:
On 05/09/2019 08:52, Alex Peshkoff via Firebird-devel wrote:
Error is error, doesn't matter where it happens. Or you could offer
"fallback" for
wrong database handle\wrong server name in isc_attach_database\not
working client DNS\etc
cases ?
Looks like finally you agreed that return a different tz value is like
dropping a different database because engine could not drop the asked
one, and no workaround should be inserted replacing region codes by
wrong offsets.
Why are you so sure that offset will be invalid? What's incorrect in
replacing TZ 'MSK' with offset +3?
Has anybody actually documented just what the problem is?
Use of single format for timestamp with timezone is not always
convenient. Conversion at client side is not always possible.
While supplying an 'offset' is fine for any single timestamp, TZ
supplies a lot more information than simply the current time offset,
it also supplies the DST rules and THIS is the area that is not being
handled well by any of the current TZ offerings. That is where a TZ
identifier to go with the time is important and the simple 'offset'
has never worked.
Lester - certainly TZ supplies more info. But to use that info client
must know rules for TZ and that is not always true. For some clients use
of an offset for this particular timestamp, provided by server, is much
better than decoding TZ information itself.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
