java.util.Date does not have a Timezone. It is not aware of TimeZone.

When you print, java picks up the default time zone.

Conceptually, you cannot have a date time without timezone. A date time has to be in one and only one zone. You may convert it to other zones, but it can never be without a zone.

If your business use case requires awareness of Time Zone, I would prefer to use Calendar class, or Joda Time. Avoid playing with Date class. If your business use cases do not require any time zone awareness, then go ahead with date. Assume all Date instances are in your default time zone.

Best thing is to use Calendar (or Joda Time). Calendar is a bit unintuitive but you will be able to get your job done. It is not without reason that Date class is mostly deprecated.

Initialize your Calendar with Timezone (check out available constructors). Use Dateformat to convert and show in UI in whatever time zone you wish to. I posted some code in your previous question. That might help you. I was stuck in a similar problem. I have dates in the DB in one time zone. To display them in another time zone on UI, you need to convert that datetime to another zone.

UPDATE: Added Joda-Time version, since question was changed from java-8 to jodatime.

If you have a Joda-Time DateTime, then use toLocalDate() and toLocalDateTime(...):

DateTime dateTime = new DateTime(2018, 1, 1, 14, 13, 04, 574);
System.out.println(dateTime);
LocalDate localDate = dateTime.toLocalDate();
System.out.println(localDate);
LocalDateTime localDateTime = localDate.toLocalDateTime(LocalTime.MIDNIGHT);
System.out.println(localDateTime);

2018-01-01T14:13:04.574-05:00
2018-01-01
2018-01-01T00:00:00.000

If you have "a Date get from Database", i.e. a java.sql.Date, then use toLocalDate() and atStartOfDay():

java.sql.Date sqlDate = new java.sql.Date(118, 0, 1);
System.out.println(sqlDate);
LocalDate localDate = sqlDate.toLocalDate();
System.out.println(localDate);
LocalDateTime localDateTime = localDate.atStartOfDay();
System.out.println(localDateTime);

2018-01-01
2018-01-01
2018-01-01T00:00

If you have a java.sql.Timestamp, use toLocalDateTime() and truncatedTo(...):

java.sql.Timestamp sqlTimestamp = new java.sql.Timestamp(118, 0, 1, 14, 13, 04, 574000000);
System.out.println(sqlTimestamp);
LocalDateTime localDateTime = sqlTimestamp.toLocalDateTime();
System.out.println(localDateTime);
localDateTime = localDateTime.truncatedTo(ChronoUnit.DAYS);
System.out.println(localDateTime);

2018-01-01 14:13:04.574
2018-01-01T14:13:04.574
2018-01-01T00:00

If you have a java.util.Date, use toInstant(), atZone(...), toLocalDate(), and atStartOfDay():

java.util.Date utilDate = new java.util.Date(118, 0, 1, 14, 13, 04);
System.out.println(utilDate);
Instant instant = utilDate.toInstant();
System.out.println(instant);
ZonedDateTime zonedDateTime = instant.atZone(ZoneId.systemDefault());
System.out.println(zonedDateTime);
LocalDateTime localDateTime = zonedDateTime.toLocalDate().atStartOfDay();
System.out.println(localDateTime);

Mon Jan 01 14:13:04 EST 2018
2018-01-01T19:13:04Z
2018-01-01T14:13:04-05:00[America/New_York]
2018-01-01T00:00

The accepted Answer is working too hard. Manipulating offsets is the province of a date-time library. Doing such work yourself is a waste of your time, and likely to be a source of bugs.

The old java.util.Date/.Calendar classes are notoriously troublesome. Avoid them. Instead use either java.time or Joda-Time.

java.time

Java 8 and later has a new java.time framework built-in.

Confused Question

Your Question is confused. You say you want to ignore time zone, yet you accept an answer that does indeed parse and process the time zone. And that answer then adjusts the result by an offset. So, it seems that you do not want to ignore the time zone.

Indeed, ignoring the time zone rarely makes sense. Perhaps you want to compare a pair of factories in Berlin and in Detroit to see if they both take a lunch break at the same time. In this case you are comparing their respective wall-clock time. The java.time framework offers the “Local” classes for this purpose: LocalDate, LocalTime, and LocalDateTime. But this is rarely needed in most business scenarios in my experience. These objects are not tied to the timeline.

So it seems that what you do want is to be able to compare date-time values across various time zones. The java.time classes do that implicitly. ZonedDateTime objects with various assigned time zones can be compared to one another with isBefore, isAfter, and isEqual methods.

Example Code

First we parse the input string.

The z pattern code means to expect and parse a time zone. The resulting date-time object will also be assigned this object if no other specific time zone is specified.

We also assign a Locale object with a human language component matching the text we expect to see in the input string. In this case, we need any Locale with English.

String input = "Oct 04, 2015 2:11:58,757 AM UTC";
DateTimeFormatter formatter = DateTimeFormatter.ofPattern( "MMM dd, yyyy K:mm:ss,SSS a z" ).withLocale( Locale.ENGLISH );

ZonedDateTime then = ZonedDateTime.parse( input, formatter );

Next we get the current time for Québec. This arbitrary choice of time zone will demonstrate further below that we can compare this ZonedDateTime object to another with a different time zone. Specifically, comparing against the UTC time zone assigned to our then object above.

ZoneId zoneId = ZoneId.of( "America/Montreal" );
ZonedDateTime now = ZonedDateTime.now( zoneId );

Do the comparison.

Boolean isThenBeforeNow = then.isBefore( now );

By the way, generally-speaking, the best practice in date-time work is to convert all your date-time values to UTC time zone for business logic, storage, and data exchange. Adjust into a time zone only as need be to satisfy a user’s expectations on-screen or in reports.

ZonedDateTime nowUtc = now.withZoneSameInstant( ZoneOffset.UTC );

Dump to console.

System.out.println( "input: " + input );
System.out.println( "then: " + then );
System.out.println( "now: " + now );
System.out.println( "isThenBeforeNow: " + isThenBeforeNow );
System.out.println( "nowUtc: " + nowUtc );

When run.

input: Oct 04, 2015 2:11:58,757 AM UTC

then: 2015-10-04T02:11:58.757Z[UTC]

now: 2015-10-19T19:28:04.619-04:00[America/Montreal]

isThenBeforeNow: true

nowUtc: 2015-10-19T23:28:04.619Z

About java.time

The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.

The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.

To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.

You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes.

Where to obtain the java.time classes?

• Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
  • Java 9 adds some minor features and fixes.
• Java SE 6 and Java SE 7
  • Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
• Android
  • Later versions of Android bundle implementations of the java.time classes.
  • For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….

The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.

Here are two ways to do it in Java:

/*
 *  Add the TimeZone info to the end of the date:
 */

String dateString = "2012-11-13 14:00:00:000";
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-M-d H:m:s:S Z");
Date theDate = sdf.parse(dateString + " UTC");

/*
 *  Use SimpleDateFormat.setTimeZone()
 */

String dateString = "2012-11-13 14:00:00:000";
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-M-d H:m:s:S");
sdf.setTimeZone(TimeZone.getTimeZone("UTC"));
Date theDate = sdf.parse(dateString);

Note that Date.parse() is deprecated (so I did not recommend it).

1, there's an inconsistency in this string. December 6, 2002, was actually a Friday, not a Tuesday. The "Tue" at the beginning of the string seems to be a mistake.

2, The newer java.time package (available in Java 8 and later) provides a more robust framework for handling date and time.

String dateStr = "Tue Dec 06 00:00:00 EDT 2002";

// Adjust the date string to omit the day of the week.
dateStr = dateStr.substring(4);

DateTimeFormatter parseFormat = DateTimeFormatter.ofPattern("MMM dd HH:mm:ss z yyyy", Locale.US);
ZonedDateTime dateTime = ZonedDateTime.parse(dateStr, parseFormat);

DateTimeFormatter outputFormat = DateTimeFormatter.ofPattern("dd/MM/yyyy");
String outputDateStr = outputFormat.format(dateTime);

System.out.println(outputDateStr);

Found out that you can clear the Timezone by using code below:

Calendar cal = Calendar.getInstance(); cal.clear(Calendar.ZONE_OFFSET);

That's the local time offset from UTC/GMT.

Is there any way to remove the Time Zone (+12:00 bit) from the dateTime object?

Yes, there is a way, but it would result in the wrong time. Assuming you live in Fiji or Kiribati, the time given is the correct time. It's expressed with (+12:00) to indicate which time zone you're in.

It results in the resultant time being 1 Jan 1970 12:00pm rather than the desired 1 Jan 1970 12:00 am.

Not in actual fact, due to the reason I've given. The desired time is 2 Jan 1970, not 1 Jan. The GMT time is 1 Jan at 12:00pm at that moment, and your local time is 2 Jan at 12:00am.

Having given you proper warning, here's how you could work around the time zone:

DateTimeFormatter df = DateTimeFormat.forPattern("yyyy-MM-dd'T'HH:mm:ss");
DateTime temp = df.parseDateTime("1970-01-02T00:00:00");
Date date = temp.toDate();
Calendar calendar = Calendar.getInstance();
calendar.setTime(date);
int offset = calendar.getTimeZone().getOffset(calendar.getTimeInMillis());
calendar.add(Calendar.MILLISECOND, offset);
calendar.setTimeZone(TimeZone.getTimeZone("UTC"));
DateTime dateTime = new DateTime(calendar);
System.out.println(dateTime);

Just keep in mind, by doing this you may be throwing away any benefit you were getting from Joda expressing time in UTC.

You can remove the time part from java.util.Date by setting the hour, minute, second and millisecond values to zero.

import java.util.Calendar;
import java.util.Date;

public class DateUtil {

    public static Date removeTime(Date date) {
        Calendar cal = Calendar.getInstance();
        cal.setTime(date);
        cal.set(Calendar.HOUR_OF_DAY, 0);
        cal.set(Calendar.MINUTE, 0);
        cal.set(Calendar.SECOND, 0);
        cal.set(Calendar.MILLISECOND, 0);
        return cal.getTime();
    }

}

I would abandon java.util.{Date, Calendar} at this point and flee to the comfort of Joda Time, where you would create a LocalDateTime. (Joda Time is a far superior date/time API.)

If you really want to stick with Calendar, you can just use the same time zone everywhere - the simplest approach being UTC as that doesn't have any daylight saving time.

Alternatively, it's not clear that you really want a Calendar without the concept of a TimeZone - but a Calendar which uses a TimeZone other than the system default - which is easy; you just set the time zone for the calendar explicitly. Of course you need to know the time zone of the other system that way...

If you can give more details of what information you know and what you need to do with it, we may be able to help you more.

do this.

setTimezone(DatatypeConstants.FIELD_UNDEFINED); 

It has to do with formatting, not timezone, but in case you want to disable timezone, then do something like this:

SimpleDateFormat sdf = new SimpleDateFormat(format);
sdf.setTimeZone(TimeZone.getTimeZone("GMT"));
return sdf.format(date);

This will set your timezone to GMT/UTC