File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Is it possible to convert a String data to Java date object without time? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Is it possible to convert a String data to Java date object without time?" Watch "Is it possible to convert a String data to Java date object without time?" New topic
Author

Is it possible to convert a String data to Java date object without time?

C Rakesh
Greenhorn

Joined: May 04, 2009
Posts: 18
Hi Friends,

I have a requirement to convert Java String to Java Date without time. That means Java date object should be in the format "DD/MM/YYYY", but no time should be attached with it. Is there any way?

Thanks,
Rakesh


SCJP 5.0, Preparing for SCWCD
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4490
    
    8

Java Date objects don't have a format, so it doesn't make sense to ask for a "Date object in the format 'DD/MM/YYYY'". It only gets a format when you decide to convert it to a String. And when you do that you can format it however you like, so it's easy to simply leave the time off.

What you can have is a Date object that has a zero time part (for a particular time zone). And if you convert from a string that doesn't have a time in it, that's generally what you'll get.
C Rakesh
Greenhorn

Joined: May 04, 2009
Posts: 18
Thanks a lot, Matthew This resolved my issue
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8427
    
  23

C Rakesh wrote:Thanks a lot, Matthew This resolved my issue

It's possibly worth adding that Joda Time does allow you to deal with dates separate from time. If you need to do any esoteric stuff with dates, I'd strongly recommend having a look at it.

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
C Rakesh
Greenhorn

Joined: May 04, 2009
Posts: 18
Thanks Winston, for this information. I'll have a look
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18989
    
    8

Winston Gutkowski wrote:It's possibly worth adding that Joda Time does allow you to deal with dates separate from time. If you need to do any esoteric stuff with dates, I'd strongly recommend having a look at it.


I've always been of the opinion that treating a date as just a date is the normal thing to do, and requiring a date to always have a time component is an esoteric decision.
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11499
    
  16

Paul Clapham wrote:I've always been of the opinion that treating a date as just a date is the normal thing to do, and requiring a date to always have a time component is an esoteric decision.

For what it's worth, I would agree. A Date should be a Date. A Time should be a time. A DateTime should have both.


There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19785
    
  20

Or Timestamp. Hey, guess what? Those are the names of the date classes in java.sql! Isn't that a coincidence!


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Rob Spoor wrote:Or Timestamp. Hey, guess what? Those are the names of the date classes in java.sql! Isn't that a coincidence!

Which would seem a good choice. Except that they have java.sql.Date extend java.util.Date, which undercuts the whole idea.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8427
    
  23

Paul Clapham wrote:I've always been of the opinion that treating a date as just a date is the normal thing to do, and requiring a date to always have a time component is an esoteric decision.

'Morning everyone. Hope you all had a good Christmas.

@Paul: I don't think there's anything particularly esoteric about it. If you base time values from an epoch - and I can't really see any better way to do it - they're bound to have an implicit date (and timezone); it's just the nature of the beast.

Personally, I always liked Access's way of doing it - something from Microsoft I actually like - storing timestamps as a floating point "number of days" from an epoch, because it splits "time" according to days (the basis of most calendars) rather than seconds. Doesn't seem to have caught on though, more's the pity.

Winston
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14432
    
  23

Winston Gutkowski wrote:Personally, I always liked Access's way of doing it - something from Microsoft I actually like - storing timestamps as a floating point "number of days" from an epoch, because it splits "time" according to days (the basis of most calendars) rather than seconds. Doesn't seem to have caught on though, more's the pity.

But as you know floating point numbers (or at least IEEE 754 floating point numbers) don't have infinite precision, you could easily get into trouble if you'd store timestamps in a float when you need to have precision to the seconds.

Accurately representing dates and times is more involved than you might think. For example, what happens on days when you switch from summer time to winter time or vice versa? Such a day has 23 or 25 hours. If you'd store a timestamp in a float with a fractional number of days, how would such a day be treated? On a normal day, an hour would be 1/24 = 0.0416667 days, but on a daylight savings switch day, an hour would be 1/23 or 1/25 day. That would be very inconvenient...

If you need to do anything with dates or times in Java, use Joda Time. In Java 8, there will be a new date and time API which will most likely look a lot like Joda Time (since it's being developed by Joda Time's author, Stephen Colebourne).

Joda Time has specialized classes for dates, times, date-and-times, with and without time zone information, periods, durations, etc. It has a really nice and well-designed API.

Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18989
    
    8

Winston Gutkowski wrote:
Paul Clapham wrote:I've always been of the opinion that treating a date as just a date is the normal thing to do, and requiring a date to always have a time component is an esoteric decision.

'Morning everyone. Hope you all had a good Christmas.

@Paul: I don't think there's anything particularly esoteric about it. If you base time values from an epoch - and I can't really see any better way to do it - they're bound to have an implicit date (and timezone); it's just the nature of the beast.


Yup, just got back from a Christmas holiday in Tofino where it didn't rain every day.

But -- I don't care about time values. I only want something which can represent "February 27, 2007". Background: I worked on my former company's Year 2000 project. We had something like 6,000 entries representing dates in the business model. Of these, fewer than 10 had a time component. Time just isn't that useful in business applications compared to Date.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8427
    
  23

Jesper de Jong wrote:Accurately representing dates and times is more involved than you might think. For example, what happens on days when you switch from summer time to winter time or vice versa? Such a day has 23 or 25 hours. If you'd store a timestamp in a float with a fractional number of days, how would such a day be treated? On a normal day, an hour would be 1/24 = 0.0416667 days, but on a daylight savings switch day, an hour would be 1/23 or 1/25 day. That would be very inconvenient...

If you look, you'll notice that I said 'a floating point "number of days" from an epoch'. I'm not talking about doing away with the system of measurement; simply with changing the way it's represented. And while I agree that floating-point values don't have infinite precision, it's good enough to store times with nanosecond[*] accuracy for the next 2,000 years or so, by which time we may have got around to changing the epoch.

The only thing that it doesn't cater for is leap-seconds; but since Java basically uses Unix time, these aren't represented anyway (at least you certainly can't get them by any normal method). Also, if the base unit of measurement is a day, do you really care if there are 86399, 86400 or 86401 seconds in it? If you really need them, it would be a simple matter to keep a table and it could be keyed by an integer (the day offset).

As I say, I just like the idea; it doesn't mean that anybody's going to listen to me. Remember Betamax.

Winston

[*] Beg pard; that's complete nonsense. What I should have said is "sub-millisecond accuracy for the next 2,000 years or so" (actually, more like 100,000). Right now, it's good for sub-microsecond accuracy, and will be for the next 100+ years.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8427
    
  23

Paul Clapham wrote:But -- I don't care about time values. I only want something which can represent "February 27, 2007". Background: I worked on my former company's Year 2000 project. We had something like 6,000 entries representing dates in the business model. Of these, fewer than 10 had a time component. Time just isn't that useful in business applications compared to Date.

I quite understand, which is why I like the idea of a floating-point representation; because then you can have your date and time systems linked numerically. Assuming we use the same epoch as now, Jan 1 1970 simply becomes day 0, and you can set up dates for any calendar system you like.

Winston

PS: How was Tofino? I hear it's great. I lived 16 years in Vancouver, and for part of that time had a girlfriend who lived in Courtney. Never got to the west side of the island though.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Is it possible to convert a String data to Java date object without time?