Timothy Madden wrote:

> Or better yet, I would ask all clients to convert all their times transferred
> to/from server to the server's time zone, since I now find that Firebird
> server does not know GMT time, so it must assume all times are in its
> time zone.

Been there got the tee shirt ;)
The second you want to share data with a server in another time zone you end
up with all sorts of contortions to get the 'correct' time. The ONLY correct
time is UTC so that is what the server should be using. Any time displays ON
the server should then give the option to display local time if needed - which
is basically how the current date/time stuff works on PHP.

> The correct solution to this problem would be for the server to always
> serve times in the client's time zone, transparently. So the same record
> would appear to hold 2:00am to a client in GMT+2, and 3:00am to a
> client living in GMT+3. It does not have to be the server who does this
> conversion, as I said the clients or fbclient.dll can do that too.

Current time possibly, but you seem to forget daylight savings which screw
everything up. Try running a railway timetable through a change of daylight
saving. The timetable usually shows the next day times an hour later or
earlier, but the movement time needs to be continuous ;) Moving the trains
through time zones as well ....
But then you contradict yourself, since the final sentence gives the exact
solution. The CLIENT end decides if to display UTC or local and can do that
based on the real local timezone data. Adding a timezone offset TO the server
simply messes things up since IT'S daylight saving will change things as well :(

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php