• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How to get Yesterday's date

 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How do I get a yesteday's date in java.sq.Date format? Appreciate if someone would provide me a sample code.

Tnx

Smitha
 
author
Posts: 4335
39
jQuery Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Use Calendar.newInstance() to get the current date then decrement it by 1 DAY using the Calendar API.
 
Marshal
Posts: 28177
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
 
smitha rai
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks TONS
 
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Another way could be:



In one line!

And I think millis in a day is already defined somewhere in the standard api (or in apache commons.)
 
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Stuart, do you know if this would work properly in areas with Daylight Savings Time, where the number of hours in a day ends up being 23 hrs for one day in the spring and 25 hrs for one day in the fall?

You may also have problems if the system clock is changed (say, for example, to sync with some central time server). I always thought this was more of a theoretical problem than a practical problem, until I saw it cause issues on a real production system.

The joys of keeping time in a distributed system....I would probably stick with using the Calendar method, let the java library sort it out, and test to make sure they got it right.
 
Stuart Ash
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I see, I hadn;t thought of these complications. Thanks for pointing it out.
 
Don Morgan
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I wasn't 100% sure about the daylight savings time issue, so I tried it out. Yep, unless I made a mistake, it is a problem.

Here's the little test code (sorry about using the deprecated api...). I scroll through the dates, moving forward in 1000 second intervals (a bit over 16 minutes). "yesterday" would be incorrect for 1hr in the spring and 1hr in the fall.



Output:

 
Scott Selikoff
author
Posts: 4335
39
jQuery Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's good that you noticed the daylight savings time issues but I suggest not getting hung up on solving it. Rather, make sure the normal case is still fast. Keep in mind that this is a problem only 0.02% time, so it fixing it shouldn't slow down the remaining 99.98% of the cases.
[ January 06, 2006: Message edited by: Scott Selikoff ]
 
Don Morgan
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Without knowing the details of what the application is for, it is not possible to establish the winner in the performance vs correctness tradeoff (even vs cost of developer time solving it!).

I think though in most cases you would be correct.
 
Paul Clapham
Marshal
Posts: 28177
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Don Morgan:
Without knowing the details of what the application is for, it is not possible to establish the winner in the performance vs correctness tradeoff (even vs cost of developer time solving it!)

I think it is possible. If the code is going to be run rarely, then the performance aspects of doing some built-in Calendar logic over subtracting a magic number are going to be so small as to be negligible. So I would use the Calendar logic there. But if it is going to be run often enough to matter, then the number of times the "magic number" version is wrong will be noticeable twice a year (in some places). So I would use the Calendar logic there too.

Or to put it more bluntly, I would use correct logic in preference to faster but incorrect logic in almost all situations.
 
Scott Selikoff
author
Posts: 4335
39
jQuery Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Paul Clapham:
Or to put it more bluntly, I would use correct logic in preference to faster but incorrect logic in almost all situations.


I think my original sentiment is that I sometimes see developers spending too much time on special cases that can rarely ever even happen. For example, if you spend 10 hours on the general solution, but 80 hours on a special case, you just have to think ahead and make sure the special case isn't a little too special, as in it almost never happens.

I'm all for correctness, but there is such a thing as going over board in special cases... with the one exception of concurrency issues. Its rare I see developers really considering concurrency issues when solving J2EE problems for things that only have 1-2 users in a test environment and thousands in a production environment.
 
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Paul Clapham:
I think it is possible. If the code is going to be run rarely, then the performance aspects of doing some built-in Calendar logic over subtracting a magic number are going to be so small as to be negligible. So I would use the Calendar logic there. But if it is going to be run often enough to matter, then the number of times the "magic number" version is wrong will be noticeable twice a year (in some places). So I would use the Calendar logic there too.

Or to put it more bluntly, I would use correct logic in preference to faster but incorrect logic in almost all situations.



Unless it's run very often and the error twice a year isn't important.
 
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How about getting it from a database server. Like, if the database is Oracle, then get it from SYSDATE.

If there is no database, then of course this will not work. But if there is one, then that is the best way to do it.

- Susanta
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Frankly it seems rather premature to worry about speed at this point. Especially if that's used as justification for sacrificing correctness. There's no reason to think the performance is critical here, or that there's a bottleneck in this area. Aside from the issue of correctness, I'd want to think about readability and maintainability here before performance. And really, the code to do this correctly is fairly simple anyway:

Sure, it was easy to overlook the issue of daylight savings in this problem. It's quite understandable. But when professional programmers deal with dates & times, issues like daylight savings and leap years are exactly the sorts of things that we should try to anticipate. Especially where there's a standard library that can handle the situation for us.

It's unusal for me to speak well of the Calendar and GregorianCalendar classes - there are a number of ways in which they could have been - should have been - designed better. But that doesn't change the fact that this sort of problem is what they were designed to do. It's worthwhile to understand the capabilities of standard Java classes - especially anything in java.lang or java.util.
[ January 07, 2006: Message edited by: Jim Yingst ]
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Excellent article, and cheers for the professional attitude to drive correctness over "premature optimization"

But I wonder how this function works to calculate getDateBefore(date) without reference to the 'date' parameter??
One might expect to see: cal.setTime(date) before cal.add(...)
 
Ranch Hand
Posts: 327
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Allow me to stick my oar in with these two comments:
1) Whose time zone?
2) Whose Daylight Savings Time?

As you are dealing with a Date instance, 1) is probably moot. The trick is to know what date you are initially parsing and making sure that you have correctly interpreted it. if the Date instance is not constructed correctly, then you will never get the correct answer and adding "fudge factors" to try and cope with time zones after the fact is fraught with danger. My personal motto in dealing with dates is that any string date without a time zone is invalid, without exception. If you are always using Calendar.getInstance() (or similar) and not having to read a date from somewhere, then you don't have to worry about this.

2) can be a gotcha even if your code looks correct (usually affects client/server applications). Not all countries move to/from Daylight Savings at the same time, so you have to ensure that the value displayed to the user makes sense to them. One example could be a user in the UK using a server hosted in the USA, if the server (or client) cannot compensate for the differences in Daylight Savings Times the user could get values that are an hour out.

Is the odd hour out an issue? Depends on your circumstances. In most cases it's probably more annoying than anything. For audit systems and regulatory compliance then you could be in serious trouble.

I normally handle all this by ensuring dates are either passed around as proper Date/Calendar instances or fully formatted Strings to UTC following SI notation (ISO-8601). I have had to spend quite a lot of time over the past few years fixing a lot of code because people simply cannot tell the time! So, for my money, I'd use Paul's method as that 0.02% could end up biting you a few years down the line.

So, repeat after me, a string date without a time zone is invalid. Always.

J.
 
Sheriff
Posts: 22781
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Please http://faq.javaranch.com/java/DontWakeTheZombies
reply
    Bookmark Topic Watch Topic
  • New Topic