This should be fixed in SVN now.
--
You received this message because you are subscribed to the Google Groups H2
Database group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to
Hello,
Sorry for resurrecting the thread when the conversation seem to have
concluded.
As in the original posting, I see a similar synchronization bottleneck in
DateTimeUtils.dateValueFromDate method on a global calendar instance:
public static long dateValueFromDate(long ms) {
Hi
I have committed a fix for this, which should cut about half of the time off.
Regards, Noel
On 2014-05-05 17:22, Lukas Eder wrote:
I was profiling a performance issue in our own software, when I noticed an
excessive amount of time being spent
in org.h2.util.DateTimeUtils.getTimeTry(),
Great, thank you very much Noel. I will get back to this once I will be
able to upgrade. I assume that the fix is available from the latest
automated build available here:
http://www.h2database.com/html/download.html
2014-05-08 8:02 GMT+02:00 Noel Grandin noelgran...@gmail.com:
Hi
I have
On 2014-05-08 12:22, Lukas Eder wrote:
Great, thank you very much Noel. I will get back to this once I will be able to
upgrade. I assume that the fix is
available from the latest automated build available here:
http://www.h2database.com/html/download.html
Should be by tomorrow morning (the
OK, so I can see that timestamps will remain the way they are in H2. That's
perfectly fine. Obviuosly, Thomas has given this some deeper thought - I,
myself tend to avoid wrapping my mind around that dreaded subject ;-)
But going back to the original issue, what would be the optimal way to:
-
Is there any solution to this?
PreparedStatement.setTimestamp(int parameterIndex, Timestamp x) gives you
the milliseconds since the Epoch without any timezone. It may be the result
of converting some future date in Middle-earth. Now the in Elbonia residing
server stores it as its local time and
Hi,
Sorry I don't understand.
PreparedStatement.setTimestamp(int parameterIndex, Timestamp x) gives you
the milliseconds since the Epoch without any timezone. It may be the result
of converting some future date in Middle-earth. Now the in Elbonia residing
server stores it as its local time
Do you recommend using strings for working with dates? Or is there
a better way?
You can use String or Timestamp in H2 1.4.x.
And on top of these two above mentioned alternatives you can store a
timestamp in bigint (milliseconds since UE in UTC).
Dates can be stored also into
Sorry for being unclear, let me retry:
In Middle-earth, the user enters 2020-10-10 00:00, which the server (based
in Elbonia, but aware about the Middle-earth's TZ) correctly translates to x
= new java.sql.Timestamp(1234568000L) and stores via ps.setTimestamp(1, x).
For a TIMESTAMP column, MySql
Hi,
In Middle-earth, the user enters 2020-10-10 00:00, ... H2 stores it as
the server's local datetime, e.g., 2020-10-10 12:30.
No, this is not what is happening. Right now, H2 stores 2020-10-10 00:00.
If you don't believe it, you can test it yourself.
Regards,
Thomas
--
You received this
Hi
Thomas, the problem you are talking about only exists when dealing with date values without time, like 1982-01-01, not
for Timestamp values.
We could store timestamps internally as a long value, defined in the same way as that System.currentTimeMillis is
defined i.e. milliseconds since 1
Intuitively, I would agree with Noel, here. The unix timestamp (plus nano
seconds) seems to be a reliable storage format. Instead of going through
all the date time hassles by operating on strings, it would be possible to
defer any string / calendar representation up to the moment when it is
On 2014-05-06 09:03, Lukas Eder wrote:
And while we're at it, to make things more interesting, have you ever
considered supporting both the SQL standard
TIMESTAMP WITHOUT TIMEZONE (your current implementation) and TIMESTAMP WITH
TIMEZONE data types? :-)
I offered to implement it here:
The good old free as in beer OSS consumer attitude :-)
But let's not get mad about this. Let me try to answer those questions:
Do you know
(a) what the most common string representation of such a datatype is
There are two candidates. ISO 8601 compliant or SQL standard compliant. The
latter
Most people just try to avoid this issue by normalising everything to
UTC and deferring timezone calculations as long as possible
Yes that is correct. And guess what ... it works perfectly!
The point where timezone becomes relevant is at the point when a
timepoint is represented to user
Hi,
H2 did store timestamps as UTC. Search for timezone in this group to see
what problems this caused. With H2 version 1.4, this is no longer the case,
and I believe this solves many issues. For example:
Let's assume somebody in Elbonia (doesn't exist, I know) today stores a
timestamp in the
2014-05-06 18:11 GMT+02:00 Thomas Mueller thomas.tom.muel...@gmail.com:
Hi,
H2 did store timestamps as UTC. Search for timezone in this group to see
what problems this caused.
I'm assuming you're talking about this thread:
https://groups.google.com/d/msg/h2-database/O5mfM1iSSow/7QMDoGXndCIJ
Let's assume somebody in Elbonia (doesn't exist, I know) today stores
a timestamp in the future, 2020-05-03 10:00:00, in H2. H2 would then
convert that to UTC, let's say that's 2020-05-03 06:30:00. When
storing that value, the rules are that this is during the daylight
saving time of
Hi,
I'm not quite sure, but you seem to assume people are interested in what
time it is UTC. But I believe in 99.9% of the case, people are interested
in local date and time only. In the Java 8 DateTime API, I assume most
people will use LocalDateTime, LocalDate, LocalTime, and not ZonedDateTime
Well, frankly I am ok with any approach since I already use succesfully
the biggint type and custom made functions for all my temporal needs.
I merely wanted to give my thoughts as a service to the community.
And completely respect your views as the owner of this project.
Sincerely,
Rami
--
Hello,
I was profiling a performance issue in our own software, when I noticed an
excessive amount of time being spent
in org.h2.util.DateTimeUtils.getTimeTry(), even if the benchmark selected
only one timestamp column with dozens of other columns:
http://i.imgur.com/KJdXEWB.png
I am a bit
Hi,
Yes, this is potentially a problem. It can be fixed in multiple ways
(always use a new Calendar, use a ThreadLocal,...). So far it didn't show
up in my tests, and so far nobody complained.
Wouldn't it be sufficient to just call new Timestamp(time)?
Well, the problem is what is the value of
I'm curious - why do we not simply store date and time in UTC format?
i.e. in milliseconds since 1 Jan 1970?
That's pretty much a universal format these days, and then we can
convert to whatever the local time zone is when we convert the value
to string.
If necessary, I could create an extra data
Hi,
There are various problems when using java.util.Data / java.sql.Date / Time
/ Timestamp and java.util.Calendar, mainly because of the daylight time
saving changes. For example, you can't assume a certain date (if you don't
care about the time) is midnight, because in some timezones, for some
25 matches
Mail list logo
