compering date with the data base

[shinshin]

hi ,
while using an SQL query i am retreiving the date with the follow
format: mm/dd/yyyy
in date instance.
while using a getstartdate() methos i am geting a calendar object with
the follow data:
mm/dd/yyyy hh:mm how can i compare both dates?

thanks,
shlomy.

 

[Arne Vajhøj]

while using an SQL query i am retreiving the date with the follow
format: mm/dd/yyyy
in date instance.
while using a getstartdate() methos i am geting a calendar object with
the follow data:
mm/dd/yyyy hh:mm how can i compare both dates?

You should both retrieve the data from the database and
from the calendar in form of java.util.Date objects and
only format to String when displaying.

Arne

 

[shinshin]

You should both retrieve the data from the database and
from the calendar in form of java.util.Date objects and
only format to String when displaying.

Arne

hi arne,
2 questions:
1. how do i cast a calendar to date.
2. how can i get only the date without the hh/mm

 

[Arne Vajhøj]

hi arne,
2 questions:
1. how do i cast a calendar to date.
2. how can i get only the date without the hh/mm

Calendar has a getTime method that returns a Date object.

On the Calendar object you can set hh, mm and ss to 0.

Arne

 

[Arne Vajhøj]

I suggest using java.sql.Date and its siblings to interact with the
java.sql interfaces like PreparedStatement and ResultSet. They are
direct subclasse of java.util.Date, set up specifically for SQL
frameworks to recognize.

This is opposite to the usual best practice of using a supertype
declaration whenever feasible, but in this case it is justified. The
java.sql type documents in the code the mapping from SQL to Java, made
precise by the choice of java.sql.Date, Time or Timestamp as the object
type.

Put another way, the java.sql classes belong to the data-access
ontology, so it's OK to use them instead of supertypes when in that
ontology.

If the database actually has a column type with date but no time,
then it is a nice solution.

But if not then I would consider it messy.

Arne

 

[Arne Vajhøj]

Which "it"?

Your solution.

For the column that uses the SQL TIMESTAMP type there is
java.sql.Timestamp, mentioned /supra/. That is the point of the
self-documenting nature of these classes. Use java.sql.Date for DATE,
java.sql.Time for TIME, and java.sql.Timestamp for TIMESTAMP.
Beautifully matched.

They match if the database has the types.

Storing a java.sql.Date in a column that only takes the date part
is perfect.

But for a database that only has one column type for date and time
that includes both data and time, then I would prefer to truncate
the time part in Java and store it as java.sql.Timestamp instead
of crossing my fingers and hope that a java.sql.Date gets
stored with only the date part.

Arne

 

[Arne Vajhøj]

I meant which of the three. I mentioned three.

I can only see one.

It had better. They are SQL standard types, all three.

Not all does.

And only for that column, of SQL type DATE. We agree here. I said as
much in my posts, as you cited.


SQL databases are supposed to have all three types, in accordance with
the SQL standard.

Not all does.

No need to hope. One can be certain that java.sql.Date stores only the
date part by making certain that it does. java.sql.Date is not made for
TIMESTAMP, and its documentation indicates as much.

You can easily verify that java.sql.Date indeed still has the hh mm ss
info in it.

<http://java.sun.com/javase/6/docs/api/java/sql/Date.html>

This is part of what makes the java.sql implementation ugly. It
wouldn't matter in a real database, but for that toy one you describe
the fix is

In a compliant database the guard step of eliminating time values could
be unnecessary, since DATE doesn't hold the time fields. Switch from
the toy database and use one that supports the SQL datetime types,
including time zones.

You can call Oracle and SQLServer for toy databases.

But ....

Arne