just for discussion's sakes :)

nothing forbids us to have db server and appserver in different
timezones, or/and multiple appservers in different timezones running on
one db in another, etc. So having dates in appserver locale, in these
case will create "strange" result when accessing data directly (except
if you send timezone with date to postgresql, but i don't know how the
other backends might behave). That, i believe, leaves us only with
option a) for db storing.

I really think appserver should behave like other servers i dealt with,
which is: treat all dates as UTC, store them as UTC (without tz info),
and leave to the client the task of displaying dates in client locale.

lekma

Currently, time zones are not considered at all in GNUe, which can lead to some
confusion if users from different time zones work on the same backend.

For communication between appserver and the client, there are two possibilities:

a) client must send all datetime values in UTC

b) client tells appserver about its timezone on session creation and sends all
datetime values in local time, appserver converts to UTC or appserver timezone.

For storing the values in DB, again several possibilities exist:

a) appserver stores all datetime values in UTC

b) appserver stores all datetime values in (appserver-)local time.

Discussion so far has shown that choosing a) on both decisions might be a good
possibility. It takes away the need for appserver to deal with different client
side timezones, and it makes it possible to move the timezone appserver runs in
without data conversion of the db.

Apart from the obviously necessary changes in the client programs (forms and
reports), there would be 2 necessary changes in appserver code:

1. appserver-generated timestamps (gnue_createdate and gnue_modifydate) must be
generated in UTC

2. the backends may not attach timezone information with stored datetime values,
because these values are UTC and not local time. This actually would be a change
in gnue-common.