On 17.6.2011 16:41, Thomas Mueller wrote:
Well, it's the same "time", of course. But it's kind of unexpected.
Specially if you happen to store things like a birthday. Suddenly a
person is born on another day...
If you are trying to represent a birthday you should use the DATE type.
DATE type is not dependent on timezone.
If on the other hand you are trying to represent the exact point in time
continuum
when you were born say 1973-16-05 23:15:00 (Helsinki time) and you want to
see what the time was at that point in time in Melbourne then the time
should
change and that point in time does happen on another day in Australia
than in Finland.
Had I been an australian and born at that same point in time I would
have my birthday
one day later.
So even though I do understand your reasons for the current
implementation and am even
sympathetic to the problems you mention I still think that the crux of
the matter is based on
misunderstanding and misusing of the temporal types.
On 17.6.2011 17:05, Panayiotis Vlissidis wrote:
I also think that since the documentation of the Timestamp class does
NOT make any reference
on Timezones and since java.util.Date specifically states that the
value is ALWAYS GMT then the
developer should NOT expect the Timezone value stored in a Timestamp
column.
I solved all my temporal problems just by using bigints instead
timestamp, date and time types.
All I needed to do on top of that was to define enough functions to
handle temporal tasks that work on
bigints. Functions that handle conversion between temporal types (if
needed) and bigints and that can take
timezone and locale as arguments if needed.
On 17.6.2011 17:05, Panayiotis Vlissidis wrote:
2) The database could have a system property for the timezone( I think
oracle works this way) and H2 apply it always
I solved this issue by adding a DatabaseListener that sets the timezone
and locale to H2 jvm that I want.
On 17.6.2011 16:31, Rami Ojares wrote:
So what we mean in this scenario is that timestamp WITHOUT timezone is
actually timestamp WITH-A-STATIC timezone, right?
To be gruesomely accurate I would call these two types as
TIMESTAMP WITH_CREATIONTIME_TIMEZONE_DEFAULT and
TIMESTAMP WITH_RUNTIME_TIMEZONE_DEFAULT
That's what we are really discussing here. But we don't see that clearly
because this default timezone is used almost everywhere a timestamp
needs to be parsed and formatted.
Just showing the timestamp to the user needs to use timezone.
Therefore the users think that the time has changed but it was only the
default timezone that had changed.
On 17.6.2011 17:05, Panayiotis Vlissidis wrote:
3) Have an extra composite custom H2 data type that can handle both
timestamp and timezone.
I am doing this already. One column (T1) has a bigint that represents
the timezone. Another column (T2) has a varchar containing the default
timezoneId Eg. 'Europe/Helsinki'.
Say I want to show the date of that timepoint in it's default timezone I say
SELECT DATE_STR(T1, T2)
FROM FOO
The fact that it is so easy to define functions in H2 makes it easy to
define the kind of temporal functions that do the deed.
On 17.6.2011 16:41, Thomas Mueller wrote:
Maybe it
would be easier to store the actual string ("1970-01-01 04:00:00")
instead of a long...
Yes certainly that would make this datetime seem less changing because
it does not represent a universal point in time anymore.
It enumerates a year, a month, a day, an hour, a minute and a second
value. But it is not clear what point in time it represents
since it could be interpreted to be a time in Swiss timezone or in an
australian timezone or even in GMT timezone, right?
It represents a varchar that only changes when updated.
Remember: The value is not the same as one of it's representations.
- 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.
