On 2017-11-21 17:49, Adriano dos Santos Fernandes wrote:
On 21/11/2017 14:16, Lester Caine wrote:
On 21/11/17 14:55, Adriano dos Santos Fernandes wrote:
Implementing TIME WITH TIME ZONE and TIMESTAMP WITH TIME ZONE
datatypes
as specified in the SQL standard is not a big problem.
The only question is just how is the timezone data managed. It is
useless simply having an offset value when large areas of the planet
still use daylight saving. If I move a meeting from March to April I
need to know the real timezone, a simple hour offset is no good at
all.
It's the same old problem as the offset provided by a browser ...
useless for half of the year ...
Time offset may be specified at absolute value (+/- HH:MM) or by region
(PST, EDT, etc).
Timezone abbreviations are imprecise and ambiguous (as there are
multiple zones with the same abbreviation, like EST is that in Australia
or in Canada, IST is that India or Ireland, etc), if we want to support
named timezones (and I think we shouldn't), then at minimum the standard
long-form names (eg Europe/Amsterdam) should be supported
Region uses daylight saving data.
Technically those have their own short names (eg CET vs CEST), which is
another reason not to use them.
I'm going to focus on absolute value only for start.
Mark
------------------------------------------------------------------------------
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
