"SET BIND OF TS WITH TZ TO VARCHAR(128)" uses the date format of dialect 1.

[dmitry-lipetsk]

FB 4.0.3.2973, database with dialect 3.

SET BIND OF TIMESTAMP WITH TIME ZONE TO varchar(128);
select timestamp '2023-08-29 01:02:03.0123 +3:0' from rdb$database;

Server returns string "29-AUG-2023 1:02:03.0123 +03:00"

I think. when client uses dialect 3, server should return "2023-08-29 1:02:03.0123 +03:00"

---

The second problem(?) - server ignores the size of VARCHAR. It returns the string with 57 symbols.

RDB$TIME_ZONES table says that TIME ZONE name can be up to 63 symbols.

---

[AlexPeshkoff]

RDB$TIME_ZONES table says that TIME ZONE name can be up to 63 symbols.
I do not know where did this 63 symbols came from. Actual maximum length is 32.

[dmitry-lipetsk]

It was reserved for the future names?

Or it is the unification with FB4-object names.

Ok.

2023-SEP-01 01:02:03.1234 tz_with_32symbols ----> 4+1+3+1+2+1+13+1+32 ==58 :)

[AlexPeshkoff]

Yep, when talking in dialect 1 overflow here is really possible. Will fix.

[dmitry-lipetsk]

The first thought of day - it is needed to check and correct the bind of TIMESTAMP and DATE, too :)

[dyemanov]

Should this ticket be closed?

[AlexPeshkoff]

The only reason why it and #7731 were not closed - I doubt should they be backported to fb4 or not. Certainly both are bugs, but IMO not too critical and (on the other hand) affecting possible end-user soft behavior (changed rules of date parsing, changed column width).

Do you have an idea?

[dyemanov]

IMHO, they should be backported.