Invalid time zone ID

[Dmitry Kovalenko]

To my surprise I can save into database the timestamp with invalid timezone ID.

For example - 40013.

Server returns that it is GMT*

Is it really OK?

I expected that server will return me "Invalid time zone ID" error :)

Regards,

Dmitry Kovalenko

[Adriano dos Santos Fernandes]

On 17/08/2023 17:52, Dmitry Kovalenko wrote:
> To my surprise I can save into database the timestamp with invalid
> timezone ID.
>
> For example - 40013.
>
> Server returns that it is GMT*
>
> Is it really OK?
>
> I expected that server will return me "Invalid time zone ID" error :)
>

"GMT*" is returned when there is no mapping found, which may be in
client only, or if server or its tz tables are downgraded.

But I do think server should not allow an invalid id entering from client.

So in this case I consider it a bug.


Adriano

[Mark Rotteveel]

I think it should produce a *warning*, not an *error*.

What happens if there is a newer Firebird versions that introduces new
time zone IDs, and a client knows those IDs, but then talks to an older
Firebird version? It might try to use that unknown time zone id. That
should be accepted, IMHO.

Mark
--
Mark Rotteveel

[Adriano dos Santos Fernandes]

On 18/08/2023 07:49, 'Mark Rotteveel' via firebird-devel wrote:
>
> What happens if there is a newer Firebird versions that introduces new
> time zone IDs, and a client knows those IDs, but then talks to an older
> Firebird version? It might try to use that unknown time zone id. That
> should be accepted, IMHO.
>

In this case I think server should be authority.

It may do conversions inside engine that will result in "GMT*", which is
not expected.

If some client needs to enter it, this server is needing an upgrade in
its timezone database.


Adriano

[Dmitry Kovalenko]

Hello.

What happens if there is a newer Firebird versions that introduces new
time zone IDs, and a client knows those IDs, but then talks to an older
Firebird version? It might try to use that unknown time zone id. That
should be accepted, IMHO.

IBProvider uses RDB$TIME_ZONES + RDB$TIME_ZONE_UTIL::TRANSITIONS and (I think) does not have any problems with OLD/NEW servers - because it does not store timezone IDs in own code :)

Regards,

Dmitry Kovalenko.

[Mark Rotteveel]

I was making an argument why it shouldn't be rejected with an error.

Mark
--
Mark Rotteveel

[Dmitry Kovalenko]

> To my surprise I can save into database the timestamp with invalid
> timezone ID.

"GMT*" is returned when there is no mapping found, which may be in
client only, or if server or its tz tables are downgraded.

Client (application) does not work with time zone ID. It works with name of time zone.

Time zone ID - it is the internal thing of the current server.

Client must read RDB$TIME_ZONES and map the name on the ID and vice versa.

The same thing is with charset name (except special cases - NONE, OCTETS and ODS charset).

For example UTF8 in FB and IB has the different IDs.

---

> or its tz tables are downgraded.

I think, in this case client must be ready for problems :)

But I do think server should not allow an invalid id entering from client.

  

So in this case I consider it a bug.

Ok. Should I create an issue?

Dmitry Kovalenko

[Adriano dos Santos Fernandes]

On 19/08/2023 04:31, Dmitry Kovalenko wrote:
> > To my surprise I can save into database the timestamp with invalid
> > timezone ID.
>
> "GMT*" is returned when there is no mapping found, which may be in
> client only, or if server or its tz tables are downgraded.
>
>
> Client (application) does not work with time zone ID. It works with name
> of time zone.
>
> Time zone ID - it is the internal thing of the current server.
>

IDs are stable and are part of Firebird API, hence can be used directly.


Adriano