On 17.6.2011 23:35, Rami Ojares wrote:
To be gruesomely accurate I would call these two types as
TIMESTAMP WITH_CREATIONTIME_TIMEZONE_DEFAULT and
TIMESTAMP WITH_RUNTIME_TIMEZONE_DEFAULT
Finally I have figured out what my problem is with the current system.
I don't find it wrong to store the default timezone of the server at the
time when timestamp is generated.
It just keeps the default behaviour of the timestamp more stable because
unless you specify it will
always be represented in the same default timezone.
But what I do protest is HIDDEN INFORMATION.
In this case it is the timezone associated with the timestamp.
Let's say I get a database with timestamps.
Then there is no way for me to know in which timezones those timestamps
are stored.
I just have to reverse engineer that by explicitly showing the time in
GMT and then comparing
it to how it is displayed without specifying a timezone.
Wouldn't you agree that the times would seem even more stable if H2
would always
store them and display them in GMT unless the user explicitly specified
a timezone
with which to parse/format a temporal literal?
Another possibility would be to define a persistent setting, say SET
TIMEZONE = '<java's timezone id>'
This would be the default timezone that the server uses to parse/format
temporal literals.
And since it would be a persistent setting it would only change when
explicitly changed and would thus not
be prone to changes in the underlying OS.
- rami
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
