> You have it. It's the version before you upgrade the table.
You mean before the server was upgraded?
> That in practice is a complexity nobody will use in this way.
I agree with you, partially. 90% developers will jsut store the timestamp with
timezone and done. Occasionally they will be su
On 24/04/2019 14:44, Adriano dos Santos Fernandes wrote:
Data should be validated/fixed when new rules are installed.
So IMO the problem is letting OS (or some shared component) be the
master of time zones rules instead of Firebird engine having its own
controlled table.
Exactly ...
And the fa
On 24/04/2019 09:57, Jiří Činčura wrote:
>> I'm not against tools to help one fix timestamps after rule change, but
>> definitively that should be tools, not the storage of values that should
>> be changed.
> What I'm trying to say, that simply storing in UTC+TZ is not enough, because
> at the min
> I'm not against tools to help one fix timestamps after rule change, but
> definitively that should be tools, not the storage of values that should
> be changed.
What I'm trying to say, that simply storing in UTC+TZ is not enough, because at
the minimum you need at least (1) the TZ data version
On 24/04/2019 03:53, Jiří Činčura wrote:
>> That is not a problem. The ambiguity exists only when transforming a
>> timestamp+TZ (as one sees it) to UTC. After parse the literal, it's
>> always in UTC+TZ.
>>
>> UTC+TZ is always transformed to a valid displayable timestamp+TZ.
> That is a BIG proble
> That is not a problem. The ambiguity exists only when transforming a
> timestamp+TZ (as one sees it) to UTC. After parse the literal, it's
> always in UTC+TZ.
>
> UTC+TZ is always transformed to a valid displayable timestamp+TZ.
That is a BIG problem. Because the TZ rules can change. So i.e. wh
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 t
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
m
11 matches
Mail list logo
