On 23/04/2019 19:10, Adriano dos Santos Fernandes wrote:
Regarding the exception, what would happen if you store valid date at
that time and you later, with new DST rules, try to read it?
That is not a problem. The ambiguity exists only when transforming a
timestamp+TZ (as one sees it) to UTC.
On 23/04/2019 14:43, Jiří Činčura wrote:
> Regarding the exception, what would happen if you store valid date at
> that time and you later, with new DST rules, try to read it?
>
>
That is not a problem. The ambiguity exists only when transforming a
timestamp+TZ (as one sees it) to UTC. After parse
Regarding the exception, what would happen if you store valid date at that time
and you later, with new DST rules, try to read it?
--
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/
On Tue, Apr 23, 2019, at 17:46, Adriano dos Santos Fernandes wrote:
> Hi!
>
> With time zones, there is some
On 4/23/19 6:45 PM, Adriano dos Santos Fernandes wrote:
Hi!
With time zones, there is some timestamps that does not exist or are
"ambiguous".
For example, timestamp '2017-10-15 00:00 America/Sao_Paulo' does not
exist as it's in the gap where DST starts and had one hour advanced.
And timestamp
Hi!
With time zones, there is some timestamps that does not exist or are
"ambiguous".
For example, timestamp '2017-10-15 00:00 America/Sao_Paulo' does not
exist as it's in the gap where DST starts and had one hour advanced.
And timestamp '2018-02-17 23:00 America/Sao_Paulo' are ambiguous as it
