Please try to keep your responses short.
I promise to try, but I find clear and explicit communication in higher
value
than the the sparsity of expression.
Now the documentation seems to me clear and concise.
It expresses everything in a pragmatic way using a concrete example.
Well done.
I feel that Dario already answered this partially but I still feel
obligated to answer this myself.
DATE and TIME types have nothing to do with timezones.
Well, currently they do. See also ResultSet.getDate and getTime(...,
Calendar cal).
I think you are mixing here the database
Hi,
DATE and TIME types have nothing to do with timezones.
Well, currently they do. See also ResultSet.getDate and getTime(...,
Calendar cal).
TIMESTAMP refers to a point of time in the whole universe that can be shared
by all possible calendar systems.
For certain use cases, yes. For other
Hi,
There is a feature request to support timestamp with timezone. I will
increase the priority.
Regards,
Thomas
--
You received this message because you are subscribed to the Google Groups H2
Database group.
To post to this group, send email to h2-datab...@googlegroups.com.
To unsubscribe
Hi,
El 12/10/10 14:55, Thomas Mueller escribió:
DATE and TIME types have nothing to do with timezones.
Well, currently they do. See also ResultSet.getDate and getTime(...,
Calendar cal).
Rami say and I agree, that date and time fields stored in a database must be
static values that should
Hi,
My project is using O-R mapping tool Datanucleus(JDO) to manipulate
database so we can easily change database.For client-server version
our database is Postgresql and in single user version we choose
H2.Conversion to H2 is smooth and H2 works great only that
Datanuclues default maps java
Hi all,
This is a very good and accurate answer to questions about timestamp and
timestamp tz data type uses that occur repeatedly, as doubts and as portability
queries from other dbms.
I propose that this explanation, a summary or similar be added as a special
note to the documentation on
Hi,
I think in most cases it's better to *not* convert the date/time to
UTC (Coordinated Universal Time) before storing, because of following
problem: Let's say you store a birthday in the database. After that,
you close the database, and move the database file to a different time
zone. Then you
There has been talks about this issue before.
I suggested that h2 should store timestamp as a long value signifying
milliseconds since Unix Epoch.
Most compact representation of time and leaves no room for
misinterpretation.
For the time being I would suggest route B.
And do all your
Hi!
My project need to support mutiple time zone.But I noticed one
strange thing about H2 that on timezone changing the queried timestamp
was not equaled to inserted one.
Environment:H2 1.2.142,JRE 1.6.0_17,Windows 7 64bit
Here is the scenario:
1.If OS time zone is GMT +8:00(China)
One car
Hi!
My project need to support mutiple time zone.But I noticed one
strange thing about H2 that on timezone changing the queried timestamp
was not equaled to inserted one.
Environment:H2 1.2.142,JRE 1.6.0_17,Windows 7 64bit
Here is the scenario:
1.If OS time zone is GMT +8:00(China)
One car
11 matches
Mail list logo
