Simple date compare

[Ulf]

I want to check if todays date <= a date retrieved from a SQL
database.

like this: if (today <= toDate)

I only want to care about the date, and not the time.

From the database I get the date with time set to all 0, but from the
today = new Date() I get the time set, and if todays date = toDate the
test will fail because the time partion is larger.

Can anyone please help me with a simple solution?

Using Calendar would be possible, but adds a lot of code.

 

[Roedy Green]

Can anyone please help me with a simple solution?

1. use BigDate. see http://mindprod.com/products1.html#COMMON11

2. get the timestamp long, and divide by the number of milliseconds in
a day to get the day number in GMT.

3. as 2, but adjust by timezone offset in millis first to get local
date.

 

[Andrea Francia]

1. use BigDate. see http://mindprod.com/products1.html#COMMON11

2. get the timestamp long, and divide by the number of milliseconds in
a day to get the day number in GMT.

This is not safe, it will not take in account the leap second.

 

[Eric Sosman]

I want to check if todays date <= a date retrieved from a SQL
database.

like this: if (today <= toDate)

I only want to care about the date, and not the time.

From the database I get the date with time set to all 0, but from the
today = new Date() I get the time set, and if todays date = toDate the
test will fail because the time partion is larger.

Can anyone please help me with a simple solution?

Using Calendar would be possible, but adds a lot of code.

Use Calendar. I think you'll find that "a lot" is
less than you fear.

 

[Lew]

This is not safe, it will not take in account the leap second.

The OP's only objection to the Calendar class is

Using Calendar would be possible, but adds a lot of code.

In other words, laziness, even if it were true, which it isn't.

Calendar lets one zero out the time fields, leaving only the date fields filled.

Calendar cal = Calendar.getInstance();
cal.set( Calendar.HOUR, 0 );
cal.set( Calendar.MINUTE, 0 );
cal.set( Calendar.SECOND, 0 );
cal.set( Calendar.MILLISECOND, 0 );

It lets you directly compare one instance to another, using
<http://java.sun.com/javase/6/docs/api/java/util/Calendar.html#compareTo(java.util.Calendar)>

That's going to be a lot less code and a lot more direct than messing with
milliseconds and timezone calculations. This time laziness is steering you in
the direction of *more* work, not less.

 

[Ulf]

The OP's only objection to the Calendar class is


In other words, laziness, even if it were true, which it isn't.

Calendar lets one zero out the time fields, leaving only the date fields filled.

   Calendar cal = Calendar.getInstance();
   cal.set( Calendar.HOUR, 0 );
   cal.set( Calendar.MINUTE, 0 );
   cal.set( Calendar.SECOND, 0 );
   cal.set( Calendar.MILLISECOND, 0 );

It lets you directly compare one instance to another, using
<http://java.sun.com/javase/6/docs/api/java/util/Calendar.html#compare...)>

That's going to be a lot less code and a lot more direct than messing with
milliseconds and timezone calculations.  This time laziness is steering you in
the direction of *more* work, not less.

Thanks for your answers.

The think is that... really I'm lazy... but since I'm converting an
old non Java application that uses a lot of dates without the time
part, I was kind of worried that I missed the simple solution.

I will just include a simple function in my utilities class that uses
Calendar to return a date with time = 0.

/Ulf

 

[Lew]

The think is that... really I'm lazy...

"Laziness" in engineering is actually a virtue. Like other skills, the trick
is knowing when to use it, and which of several alternatives is truly the lazier.

but since I'm converting an
old non Java application that uses a lot of dates without the time
part, I was kind of worried that I missed the simple solution.

In this case, Calendar is the simple solution.

 

[Roedy Green]

This is not safe, it will not take in account the leap second.

leap seconds in Java are handled by adjustments to the clock.
Computationally they don't exist.

 

[Roedy Green]

Calendar lets one zero out the time fields, leaving only the date fields filled.

Calendar cal = Calendar.getInstance();
cal.set( Calendar.HOUR, 0 );
cal.set( Calendar.MINUTE, 0 );
cal.set( Calendar.SECOND, 0 );
cal.set( Calendar.MILLISECOND, 0 );

It lets you directly compare one instance to another, using
<http://java.sun.com/javase/6/docs/api/java/util/Calendar.html#compareTo(java.util.Calendar)>

That's going to be a lot less code and a lot more direct than messing with
milliseconds and timezone calculations. This time laziness is steering you in
the direction of *more* work, not less.

But if you HAVE to think about timezones to define what you mean by
"today".

What you are doing is looking ahead to the day when the planet uses
UTC without timezones.

 

[Roedy Green]

Use Calendar. I think you'll find that "a lot" is
less than you fear.

On the other paw, make sure you cross check you answers with manual
calculation. There are a million ways to get results, but not the
results you intended from Calendar.

see http://mindprod.com/jgloss/calendar.html
for some of the pitfalls.

Also make sure your code works for different timezones or when client
and server are in different timezones.

 

[Andrea Francia]

leap seconds in Java are handled by adjustments to the clock.
Computationally they don't exist.

Could you provide a reference for this affirmation, I'm interested.
Thanks

 

[sla29970]

This is true for a POSIX-compliant system clock. Other system clocks
may count leap seconds.

Could you provide a reference for this affirmation, I'm interested.
Thanks

I'll offer these
http://www.ucolick.org/~sla/leapsecs/timescales.html#POSIX
http://www.ucolick.org/~sla/leapsecs/onlinebib.html#POSIX

 

[Jacob]

http://geosoft.no/software/day/Day.java.html