Mark,
Dne 09. 07. 20 v 13:47 Mark Rotteveel napsal(a):
Again, it's not correct, it's just consistent/invariant across calendar.
Please explain exactly which aspects are not correct according to you.
If the goal is to produce a consistent value at a named zone, this is
the only way to do it in a dateless type.
The central point of our dispute is that TIME WITH TZ is pointless for
calculation, so any recalculation you do on storage/retrieval just puts
mud into waters even more.
The TIME WITH TZ is just a wall clock at given region (24h cycle) +
information of origin where (region) the wall clock was sampled. You
can't compare times from two regions neither from the same region that
has DST or other time-shifts, as the result is meaningless. Imagine you
store time 20:35 in region that is UTC+02:00 and then you compare it to
time 23:35 in region that is UTC+08:00. What meaningful information you
will get? How conversion to UTC will help you to get any meaningful
information out of it?
The only meaningful information stored TIME WITH TZ is the association
between wall clock and it's origin in single column. So, it should be
stored as is (the actual value when it was sampled). When I sample 12:30
then it's 12:30 where I'm and it doesn't matter whether DST is in effect
or not. The recalculation to UTC requires use of fixed date, so you
actually remove the only one meaningful information - exact time +
origin info, because you change the time I want to store, adding nothing
useful. If I would need comparisons and calculations that make sense,
I'd use TIMESTAMP and not TIME.
The rule I described was for a *TIME WITH TIME ZONE*, not for a
*TIMESTAMP WITH TIME ZONE*, so, given the limitations of *TIME WITH TIME
ZONE*, the rebasing is necessary. I don't rebase to a different date
when handling *TIMESTAMP WITH TIME ZONE* values.
I see, I was mislead by fact that you rebase the date in datetime object
as well.
What I do is exactly what needs to be done to be able to consistently
reconstruct a value, so instead what you claim without base that I
consider it acceptable to have inconsistent data, that consistency is
the cornerstone of what and why I do this (and to be honest, I kind of
resent your implication that what I'm doing is shoddy work).
The problem is that you look at it too technically from Firebird &
driver POV, so you see your solution as correct one - because
technically it is correct at this level. But from app. developer POV
it's plain wrong, because what is stored is not what is read back under
all conditions. App devs. don't care about Firebird's and driver's
difficulties and methods, it's just a black box storage. Data can change
format, but not meaning, and output time that differs from input one is
not what one would expect or wants.
The only difference is that when retrieving a ZonedDateTime (which is
the only datetime type in Java that preserves named zones), I rebase to
the current-date, to have similar behaviour as what Firebird does when
casting TIME WITH TIME ZONE to a TIMESTAMP WITH TIME ZONE. On storing a
ZonedDateTime, it does the same as what happens when casting a TIMESTAMP
WITH TIME ZONE to a TIME WITH TIME ZONE.
Again, you perfectly and correctly replicated the Firebird's (IMHO)
senseless behavior of comparing apples to oranges.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
