MySQL does support JDBC escape functions in their JDBC driver.
Robert Enyedi wrote:
Dan,
I did not know of the JDBC escape functions. These work indeed with
Derby, however the MySQL JDBC driver does not seem to support them (we
need to run our queries on both Derby and MySQL).
I know that
Dan,
My timestamp computations were all local, but as mentioned in my
previous post I managed to solve the issue.
Regards,
Robert
Daniel John Debrunner wrote:
Robert Enyedi wrote:
This is exactly what I've been trying to do. The difficulty which I'm
unable to overcome yet is that the ti
Donald,
Thanks for the code snippet. This is also what I tried to do. However, a
modification is required so that the timezone is explicitly set:
Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("UTC"));
Otherwhise the miliseconds will be those from your own timezone (which
most prob
Dan,
I did not know of the JDBC escape functions. These work indeed with
Derby, however the MySQL JDBC driver does not seem to support them (we
need to run our queries on both Derby and MySQL).
I know that this is not the best place to ask, but does anyone happen to
know more about the statu
Ok, then your best bet is probably to explicitly zero out the non-date parts:
Calendar cal = Calendar.getInstance();
cal.setTime(yourDateObject);
cal.set(Calendar.HOUR_OF_DAY, 0);
cal.set(Calendar.MINUTE, 0);
cal.set(Calendar.SECOND, 0);
cal.set(Calendar.MILLISECOND, 0);
Donald
--
Robert Enyedi wrote:
> This is exactly what I've been trying to do. The difficulty which I'm
> unable to overcome yet is that the timestamp returned by
> java.sql.Date.getTime() is not divisible with the number of miliseconds
> in a day (24 * 60 * 60 * 1000). Yet when I create a java.util.Date()
>
Robert Enyedi wrote:
> Michael,
>
> As far as I know, year 0 in MySQL is actually 1 AD. However, it doesn't
> necessarily matter when that year is when you have the comparability of
> the results.
>
> What matters that this function in combination with its reverse,
> FROM_DAYS, allows easily for
This is exactly what I've been trying to do. The difficulty which I'm
unable to overcome yet is that the timestamp returned by
java.sql.Date.getTime() is not divisible with the number of miliseconds
in a day (24 * 60 * 60 * 1000). Yet when I create a java.util.Date()
instance with that timestam
Java calendar and date objects work in miliseconds but I think that fields
marked as "date" rather than timestamp just have their hour/minute/second parts
set to 0. Even so, it's fairly easy to roll a timestamp back to 00:00:00. You
can then subtract the Date.getTime() values and divide by 86,40
Michael,
As far as I know, year 0 in MySQL is actually 1 AD. However, it doesn't
necessarily matter when that year is when you have the comparability of
the results.
What matters that this function in combination with its reverse,
FROM_DAYS, allows easily for one to compute things like:
- a
On Friday 15 September 2006 7:15 am, Robert Enyedi wrote:
> The TO_DAYS() function returns the number of days since year 0. Did
> someone successfully port this functionality to Derby? Constructing a
> Java function for this is not as straightforward as it looks.
>
> Regards,
> Robert
Why?
When wa
The TO_DAYS() function returns the number of days since year 0. Did
someone successfully port this functionality to Derby? Constructing a
Java function for this is not as straightforward as it looks.
Regards,
Robert
12 matches
Mail list logo
