On 13/06/2019 17: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 ? > Do you even worked with a library doing datetime logic in a way suitable for multiple time zones?
Every one stores the UTC time more the region _or_ offset. The displayable value is calculated only when one wants to display the value. Every one who tries to store adjusted time fails, including: 1) Me, in first tries to create the feature 2) Windows, which by default does it (in relation to hardware clock) and cannot even dual boot correctly with others OS To store adjusted datetime for a region-based value, it's also needed to store the offset (in other words, to store the adjusted datetime it's also necessary to store the UTC datetime), otherwise one cannot convert it back to UTC. We surely does not want a wrong data structure for datetime values informed by user before flow from client to server. I will stop repeating myself explaining the same thing again and again. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
