On 11/06/2019 11:41, Paul Reeves wrote: > On Tue, 11 Jun 2019 11:10:54 -0300 > Adriano dos Santos Fernandes <adrian...@gmail.com> wrote: > >> On 11/06/2019 11:08, Dimitry Sibiryakov wrote: >>> 11.06.2019 15:41, liviuslivius wrote: >>>> Can i ask what is the problem? When i retrive data by client lib it >>>> try to convert it to local timezone or what? >>> Copy isql + fbclient.dll somewhere, connect to any database, >>> select current_timestamp from rdb$database - BOOM! >>> >>> >> Copy isql + fbclient.dll somewhere, connect to any database, select >> 1 / 0 from rdb$database - BOOM! >> > But there is a difference - there is no existing, working code in > production that uses 1 / 0. But there will be code that uses > current_timestamp. Not only that, working code will expect > current_timestamp to retain the existing format. > > It seems to me that the implementation of CURRENT_TIME/STAMP is the > wrong way round. It should support the old behaviour. Instead of > introducing LOCALTIME/STAMP to return current time without the zone > we should introduce new variables that return time zones for those > that need them. > > That may not solve the problem in [subject] but it will ease the pain > of migration for many of our users. > > The pain of migration was already agreed and solved introducing LOCALTIMESTAMP in previous versions.
So should be no existing code using CURRENT_TIMESTAMP, if there is, smart users (our users) will detect in development/test times. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
