not able to convert \ format java.util.Date to yyyy-mm-dd

105 Views Asked by At

I am trying to convert java.util.Date to java.util.Date but in different format

Wed Oct 11 10:00:00 CDT 2023 --> 2023-10-11T10:00:00.000Z

I show lot of post and also tried different solutions below but no luck.

converted Date to String and again into Date but format doesn't change.

  Date utilDate = Wed Oct 11 10:00:00 CDT 2023 // Your java.util.Date

        // Define the desired format
        SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

        // Convert the java.util.Date to a formatted String
        String formattedDate = dateFormat.format(utilDate);

        System.out.println("Formatted Date String: " + formattedDate);
//convert String again into java.util.Date
// it will return the same utilDate.

Also tried with 2 SimpleDateFormat object. Please guide me further.

1

There are 1 best solutions below

0
On
  1. java.util.Date is a lie. It does not represent dates. It represents moments in time, without a timezone. There's a reason almost every method on Date (such as .getYear()) is deprecated: It is not possible to ask an instant in time 'what year is that'. Not without involving timezones at the very least.

  2. Date objects don't have a format. They contain, literally, 1 long field with epoch millis. Instead, anytime you want to turn a date into, say, pixels on a screen (e.g. you try to toss one at System.out.println, or jLabel.setText(dateHere), or toss it in a template context object which is then used to render an HTML template), you choose, every time, how to turn this wrapper-around-epochmillis-with-a-silly-name into those pixels / characters. There is no way to modify how Date's toString() implementation renders it, and in general toString() is solely to be used as a debugging aid, never as part of your business logic (that soup isn't consumed quite as hot as I just put it, but especially if you're inexperienced or new to java, that's the rule of thumb to adhere to until you've gotten much more experience).

Hence, there is no direct answer available to your question because your question's specifics do not make any sense. It's like asking: "How do I paint my walls with the colour 'fish'. Which screwdriver should I use?" - a series of non-sequiturs.

But the spirit is obvious enough.

Thus:

  1. Use java.time. Stop using java.util.Date. If you're forced into it, because a thing you do not directly control provides it to you, then double check that there isn't a better way (example: If using JDBC to talk to a database, don't call .getDate(colIdx). Call .getObject(colIdx, LocalDate.class)). If there really isn't treat it the same way you treat any broken code you are forced to work with: Wrap it with a 'cleaner' - ensure that the bad thing doesn't infect your code base. Write a method that takes that j.u.Date from the external thing you cannot change and modifies it immediatly to whatever is actually appropriate here (could be LocalDate, could be ZonedDateTime, could be Instant - without you explaining what this is for, there is no way to know. Date/time reckoning is far too complex for a 'one type covers all needs' solution).

  2. Use DateTimeFormatter (java.time's version of SimpleDateFormat).

  3. If you need to convert reckoning, do not go via formatting and parsing. Formatting and parsing is for just that - to transfer a concept of some point in time from human fingers to computers and from computers to human eyeballs. java.time objects have ways to go from one to the other. Have a LocalDateTime and need to make that a zoned thing? There are methods on LDTs to make ZDTs out of them. Their parameters guide you in this process (For example, to do that, you will need to specify a time zone). Do you need to convert from one zone to another? Take your LDT, convert it to a ZDT, convert that to a ZDT in a different zone, convert that back to an LDT.