On 2019-06-13 22:05, Vlad Khorsun wrote:
13.06.2019 16:44, Alex Peshkoff via Firebird-devel wrote:
On 13.06.2019 12:43, Vlad Khorsun wrote:
First, you loose things. The adjusted (displayable) timestamp is not
convertible back for duplicated timestamps (DST end).
Not sure i got you. Could you provide an example ?
At 03:00:00 due to DST change time is set to 02:00:00. To what UTC
corresponds 02:30:00?
It is fully depends on region name and date part of timestamp with
TZ, but...
It seems you not read my answer to the end.
User pass to the server some timestamp and specify in what TZ it was
set.
At least user think he pass data in this form.
Why we return back UTC instead of original region timestamp ? Why
conversion
to the original (region) value must be done by client ? What benefits
for client
it have ?
To repeat part of my other reply:
I prefer the current approach where the time is communicated in UTC with
the offset or region information added for presentation purposes. Having
the time in UTC will always allow a fallback to at least a usable value
instead of having a meaningless value if the region is unknown or - for
example - the offset is invalid (eg the maximum range of offsets
supported by Firebird is wider than the range of offsets supported by
Java).
Mark
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
