On 02/05/18 20:22, Adriano dos Santos Fernandes wrote:
On 02/05/2018 13:16, Lester Caine wrote:
On 29/04/18 21:47, Adriano dos Santos Fernandes wrote:
But standard CURRENT_TIME and CURRENT_TIMESTAMP works different than
Firebird, as they returns the "WITH TIME ZONE" types.
Tweaking CURRENT_TIME/CURRENT_TIMESTAMP for compatibility is
problematic.
So how do I maintain a functional system where the server has been
configured PROPERLY and is using UTC current time? Timezone is not
something that should be rammed down our throats if we are already
managing it properly with a clean timestamp and managing the display
of that data based on a client login or other local time indication. I
don't want CURRENT_TIME to be loaded with a timezone.
As said, if you want to update server, I propose backward compatibility
via LOCALTIME in old versions.
If you want a stable (say, I system that should not update), don't
update the server too.
I think we should agree that for Firebird a expression
CURRENT_TIME_AS_IN_THE_SQL_STANDARD will not be good. :)
It's funny as you being one of the most interested in have timezone in
Firebird not liking to do any easy work on your systems to adjust.
My problem with all of this is that in most cases what is being provided
in other databases is NOT timezone, but simply a random offset. The
whole problem starts with the browser timezone flag which is anything
but! There is no timezone flag provided so no way of knowing just what
the time will be in a few months time. I'm perfectly happy with the
proper solution to the problem which stores UTC normalised times and a
correct timezone flag is a separate field.
The last thing any good international system needs is storing everything
in server local time. A good example I saw only today is parcel tracking
where local times are used to display events ... so in my view a parcel
departed some depots before it arrived! I see the current 'solution' as
anything but useful in the bigger system of things.
As of today even the TZ database can't agree on how to identify timezone
rules, and names that were used last year have been changed. These also
don't match windows names for the same timezone. Just which set of rules
is safe to use going forward? Perhaps when a tzdist service is finally
available we might have a chance of making some real progress ...
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
