I have 2 files In my code :
File 1 Content :
public static final SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss");
public static final SimpleDateFormat formatter = new SimpleDateFormat("yyyy-MM-dd");
File 2 Content :
sdf.format(formatter.parse("2015-02-02")));
Issue : Line above in file 2 prints "2015-02-02 12:00:00" initially for few hours , but after that it prints "2015-02-01 06:00:00" .
Any idea what could be the issue here.
Additional info :
My server is running on some cloud machine located in US .
new java.util.Date( ) gives UTC timezone value correctly all the time.
Server is started using command java -jar xyz.jar.
There are other files which are using sdf and formatter variables.
I am unable to reproduce this on local machine.
Once the issue starts happening on servers, it shows wrong date time until server is restarted.
If you check the official Oracle documentation, it says that
Date formats are not synchronized. It is recommended to create
separate format instances for each thread. If multiple threads access
a format concurrently, it must be synchronized externally.
By looking at your code, you seem to be reusing the same instance across multiple threads. That is incorrect!!!
Either maintain a pool of formatters OR synchronize the access (not recommended) OR you can create a new instance every time.
The comments by Nathan Hughes and myself are good enough to be combined into an answer: Use java.time, the modern date time API, and specifically its DateTimeFormatter.
public static final DateTimeFormatter printFormatter
= DateTimeFormatter.ofPattern("uuuu-MM-dd HH:mm:ss");
Now your formatting may for example go like this:
String stringToPrint = LocalDate.parse("2015-02-02")
.atStartOfDay(ZoneOffset.UTC)
.format(printFormatter);
System.out.println(stringToPrint);
This prints:
2015-02-02 00:00:00
In the format conversion code I am taking advantage of the fact that your original string, 2015-02-02, is in the standard ISO 8601 format for a date. LocalDate parses this format as its default, that is, without any explicit formatter.
What went wrong in your code?
It would seem from your question that there are two likely explanations for the behaviour you have observed:
One of the other classes of the program on the server that uses the two formatters, sets the time zone of one of them, for example to America/Chicago.
Two or more threads use the formats simultaneously, which causes one of them to behave incorrectly.
The observed behaviour, an error of 6 hours, where after it has turned up, it continues until server restart, seems more consistent with the first explanation, which you also confirmed in your own answer, and thank you for doing that.
Contrary to SimpleDateFormat the modern DateTimeFormatter is thread-safe, which prevents any thread problems, and immutable, which prevents other classes from modifying the formatter. So it solves your problem in both cases.
As an aside, I think you are aware of your incorrect use of lowercase hh in the format pattern string. hh is for hour within AM or PM from 01 through 12, whereas you need uppercase HH for hour of day from 00 through 23 (this goes both for SimpleDateFormat and for DateTimeFormatter).
Link: Oracle tutorial: Date Time explaining how to use java.time.
Timezone was getting set for sdf by some piece of code in another api , which was causing the issue.Here is sample example to replicate the issue locally :
import java.text.SimpleDateFormat;
import java.util.TimeZone;
public class SimpleDateFormatTExample {
private static SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss");
private static SimpleDateFormat formatter = new SimpleDateFormat("yyyy-MM-dd");
private static String timeZone = "CST";
public static void main(String[] args) {
//-Duser.timezone=UTC
try {
String dateTimeString1 = sdf.format(formatter.parse("2018-01-01"));
System.out.println("Thread Main->> " + dateTimeString1);
//output : Thread Main->> 2018-01-01 12:00:00
} catch (Exception e) {
e.printStackTrace();
}
new Thread(() -> {
try {
//timezone is changed by another thread
sdf.setTimeZone(TimeZone.getTimeZone(timeZone));
String dateTimeString = sdf.format(formatter.parse("2018-01-01"));
System.out.println("Thread child->> " + dateTimeString);
//output : Thread child->> 2017-12-31 06:00:00
} catch (Exception e) {
e.printStackTrace();
}
}).start();
try {
Thread.sleep(1000);
String dateTimeString1 = sdf.format(formatter.parse("2018-02-15"));
System.out.println("Thread Main:After timezone changes by another thread->> " + dateTimeString1);
//output : Thread Main:After timezone changes by another thread->> 2018-02-14 06:00:00
} catch (Exception e) {
e.printStackTrace();
}
}
}
I am working on a REST API which supports Date as a query param. Since it is Query param it will be String. Now the Date can be sent in the following formats in the QueryParams:
yyyy-mm-dd[(T| )HH:MM:SS[.fff]][(+|-)NNNN]
It means following are valid dates:
2017-05-05 00:00:00.000+0000
2017-05-05 00:00:00.000
2017-05-05T00:00:00
2017-05-05+0000
2017-05-05
Now to parse all these different date-times i am using Java8 datetime api. The code is as shown below:
DateTimeFormatter formatter = new DateTimeFormatterBuilder().parseCaseInsensitive()
.append(DateTimeFormatter.ofPattern("yyyy-MM-dd[[ ][['T'][ ]HH:mm:ss[.SSS]][Z]"))
.toFormatter();
LocalDateTime localDateTime = null;
LocalDate localDate = null;
ZoneId zoneId = ZoneId.of(ZoneOffset.UTC.getId());
Date date = null;
try {
localDateTime = LocalDateTime.parse(datetime, formatter);
date = Date.from(localDateTime.atZone(zoneId).toInstant());
} catch (Exception exception) {
System.out.println("Inside Excpetion");
localDate = LocalDate.parse(datetime, formatter);
date = Date.from(localDate.atStartOfDay(zoneId).toInstant());
}
As can be seens from the code I am using DateTimeFormatter and appending a pattern. Now I am first trying to parse date as LocalDateTime in the try-block and if it throws an exception for cases like 2017-05-05 as no time is passed, I am using a LocalDate in the catch block.
The above approach is giving me the solution I am looking for but my questions are that is this the standard way to deal with date sent as String and is my approach is in line with those standards?
Also, If possible what is the other way I can parse the different kinds of date (shown as the Valid dates above) except some other straightforward solutions like using an Array list and putting all the possible formats and then using for-loop trying to parse the date?
DateTimeFormatter formatter = new DateTimeFormatterBuilder()
.append(DateTimeFormatter.ISO_LOCAL_DATE)
// time is optional
.optionalStart()
.parseCaseInsensitive()
.appendPattern("[ ]['T']")
.append(DateTimeFormatter.ISO_LOCAL_TIME)
.optionalEnd()
// offset is optional
.appendPattern("[xx]")
.parseDefaulting(ChronoField.HOUR_OF_DAY, 0)
.parseDefaulting(ChronoField.OFFSET_SECONDS, 0)
.toFormatter();
for (String queryParam : new String[] {
"2017-05-05 00:00:00.000+0000",
"2017-05-05 00:00:00.000",
"2017-05-05T00:00:00",
"2017-05-05+0000",
"2017-05-05",
"2017-05-05T11:20:30.643+0000",
"2017-05-05 16:25:09.897+0000",
"2017-05-05 22:13:55.996",
"2017-05-05t02:24:01"
}) {
Instant inst = OffsetDateTime.parse(queryParam, formatter).toInstant();
System.out.println(inst);
}
The output from this snippet is:
2017-05-05T00:00:00Z
2017-05-05T00:00:00Z
2017-05-05T00:00:00Z
2017-05-05T00:00:00Z
2017-05-05T00:00:00Z
2017-05-05T11:20:30.643Z
2017-05-05T16:25:09.897Z
2017-05-05T22:13:55.996Z
2017-05-05T02:24:01Z
The tricks I am using include:
Optional parts may be included in either optionalStart/optionalEnd or in [] in a pattern. I use both, each where I find it easier to read, and you may prefer differently.
There are already predefined formatters for date and time of day, so I reuse those. In particular I take advantage of the fact that DateTimeFormatter.ISO_LOCAL_TIME already handles optional seconds and fraction of second.
For parsing into an OffsetDateTime to work we need to supply default values for the parts that may be missing in the query parameter. parseDefaulting does this.
In your code you are converting to a Date. The java.util.Date class is long outdated and has a number of design problems, so avoid it if you can. Instant will do fine. If you do need a Date for a legacy API that you cannot change or don’t want to change just now, convert in the same way as you do in the question.
EDIT: Now defaulting HOUR_OF_DAY, not MILLI_OF_DAY. The latter caused a conflict when only the millis were missing, but it seems the formatter is happy with just default hour of day when the time is missing.
I usually use the DateUtils.parseDate which belongs to commons-lang.
This method looks like this:
public static Date parseDate(String str,
String... parsePatterns)
throws ParseException
Here is the description:
Parses a string representing a date by trying a variety of different parsers.
The parse will try each parse pattern in turn. A parse is only deemed successful if it parses the whole of the input string. If no parse patterns match, a ParseException is thrown.
The parser will be lenient toward the parsed date.
#Configuration
public class DateTimeConfig extends WebMvcConfigurationSupport {
/**
* https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#format-configuring-formatting-globaldatetimeformat
* #return
*/
#Bean
#Override
public FormattingConversionService mvcConversionService() {
DefaultFormattingConversionService conversionService = new DefaultFormattingConversionService(false);
conversionService.addFormatterForFieldAnnotation(new NumberFormatAnnotationFormatterFactory());
// Register JSR-310 date conversion with a specific global format
DateTimeFormatterRegistrar dateTimeRegistrar = new DateTimeFormatterRegistrar();
dateTimeRegistrar.setDateTimeFormatter(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"));
dateTimeRegistrar.setDateTimeFormatter(DateTimeFormatter.ofPattern("yyyy-MM-dd"));
dateTimeRegistrar.setDateTimeFormatter(DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss'Z'"));
dateTimeRegistrar.registerFormatters(conversionService);
// Register date conversion with a specific global format
DateFormatterRegistrar dateRegistrar = new DateFormatterRegistrar();
dateRegistrar.setFormatter(new DateFormatter("yyyy-MM-dd"));
dateRegistrar.setFormatter(new DateFormatter("yyyy-MM-dd HH:mm:ss"));
dateRegistrar.setFormatter(new DateFormatter("yyyy-MM-dd'T'HH:mm:ss'Z'"));
dateRegistrar.registerFormatters(conversionService);
return conversionService;
}
}
I'm new in OFBiz, and Java. I used bellow block of code for checking date time input and use that for searching in table.
Timestamp strtDate = UtilDateTime.getTimestamp((String)request.getParameter("strt_date"));
if(strtDate != null)
{
// then here i used the date for taking data.
}
When i fill the date time field of form to search or when no date is selected for searching error occure that show numberFormatException, so how i can solve that? thanks for any help and guide.
Based on the Apache ofbiz API it looks like UtilDateTime#getTimestamp(String) expects milliseconds value. You are passing in "2014-01-12 05-44-56". You need to parse your date first. With pure pre 1.8 java (keep in mind that formatters aren't thread safe):
String dateString = "2014-01-12 05-44-56";
SimpleDateFormat formatter = new SimpleDateFormat("yyyy-MM-dd HH-mm-ss");
Date date = formatter.parse(dateString);
UtilDateTime.getTimestamp(date.getTime());
Since java 1.8 (highly recommended to switch if you can!):
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH-mm-ss");
ZonedDateTime date = ZonedDateTime.parse(text, formatter);
long millis = date.toInstant().toEpochMilli();
you have to pass time in milliseconds not as you are passing.
you can check code also :
public static Timestamp getTimestamp(String milliSecs) throws NumberFormatException {
return new Timestamp(Long.parseLong(milliSecs));
}
it will parse the data in long which you are passing and that should be valid long value.
request.getParameter("strt_date") will anyways return String, so no need to cast it explicitly to String. Moreover, there will be a contract between Client & Server on the required Date Format. So you have to parse the String-Date in the same format using SimpleDateFormat. Code outlook will look like bellow:
SimpleDateFormat formatter = new SimpleDateFormat("contract-date-format");
Date date = formatter.parse(request.getParameter("strt_date"));
UtilDateTime.getTimestamp(date.getTime());
I want to remove time from Date object.
DateFormat df;
String date;
df = new SimpleDateFormat("dd/MM/yyyy");
d = eventList.get(0).getStartDate(); // I'm getting the date using this method
date = df.format(d); // Converting date in "dd/MM/yyyy" format
But when I'm converting this date (which is in String format) it is appending time also.
I don't want time at all. What I want is simply "21/03/2012".
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();
}
}
The quick answer is :
No, you are not allowed to do that. Because that is what Date use for.
From javadoc of Date :
The class Date represents a specific instant in time, with millisecond precision.
However, since this class is simply a data object. It dose not care about how we describe it.
When we see a date 2012/01/01 12:05:10.321, we can say it is 2012/01/01, this is what you need.
There are many ways to do this.
Example 1 : by manipulating string
Input string : 2012/01/20 12:05:10.321
Desired output string : 2012/01/20
Since the yyyy/MM/dd are exactly what we need, we can simply manipulate the string to get the result.
String input = "2012/01/20 12:05:10.321";
String output = input.substring(0, 10); // Output : 2012/01/20
Example 2 : by SimpleDateFormat
Input string : 2012/01/20 12:05:10.321
Desired output string : 01/20/2012
In this case we want a different format.
String input = "2012/01/20 12:05:10.321";
DateFormat inputFormatter = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss.SSS");
Date date = inputFormatter.parse(input);
DateFormat outputFormatter = new SimpleDateFormat("MM/dd/yyyy");
String output = outputFormatter.format(date); // Output : 01/20/2012
For usage of SimpleDateFormat, check SimpleDateFormat JavaDoc.
Apache Commons DateUtils has a "truncate" method that I just used to do this and I think it will meet your needs. It's really easy to use:
DateUtils.truncate(dateYouWantToTruncate, Calendar.DAY_OF_MONTH);
DateUtils also has a host of other cool utilities like "isSameDay()" and the like. Check it out it! It might make things easier for you.
What about this:
Date today = new Date();
SimpleDateFormat sdf = new SimpleDateFormat("dd/MM/yyyy");
today = sdf.parse(sdf.format(today));
What you want is impossible.
A Date object represents an "absolute" moment in time. You cannot "remove the time part" from it. When you print a Date object directly with System.out.println(date), it will always be formatted in a default format that includes the time. There is nothing you can do to change that.
Instead of somehow trying to use class Date for something that it was not designed for, you should look for another solution. For example, use SimpleDateFormat to format the date in whatever format you want.
The Java date and calendar APIs are unfortunately not the most well-designed classes of the standard Java API. There's a library called Joda-Time which has a much better and more powerful API.
Joda-Time has a number of special classes to support dates, times, periods, durations, etc. If you want to work with just a date without a time, then Joda-Time's LocalDate class would be what you'd use.
edit - note that my answer above is now more than 10 years old. If you are using a current version of Java (Java 8 or newer), then prefer to use the new standard date and time classes in package java.time. There are many classes available that represent just a date (day, month, year); a date and time; just a time; etc.
Date dateWithoutTime =
new Date(myDate.getYear(),myDate.getMonth(),myDate.getDate())
This is deprecated, but the fastest way to do it.
May be the below code may help people who are looking for zeroHour of the day :
Date todayDate = new Date();
GregorianCalendar todayDate_G = new GregorianCalendar();
gcd.setTime(currentDate);
int _Day = todayDate_GC.get(GregorianCalendar.DAY_OF_MONTH);
int _Month = todayDate_GC.get(GregorianCalendar.MONTH);
int _Year = todayDate_GC.get(GregorianCalendar.YEAR);
GregorianCalendar newDate = new GregorianCalendar(_Year,_Month,_Day,0,0,0);
zeroHourDate = newDate.getTime();
long zeroHourDateTime = newDate.getTimeInMillis();
Hope this will be helpful.
you could try something like this:
import java.text.*;
import java.util.*;
public class DtTime {
public static void main(String args[]) {
String s;
Format formatter;
Date date = new Date();
formatter = new SimpleDateFormat("dd/MM/yyyy");
s = formatter.format(date);
System.out.println(s);
}
}
This will give you output as21/03/2012
Or you could try this if you want the output as 21 Mar, 2012
import java.text.*;
import java.util.*;
public class DtTime {
public static void main(String args[]) {
Date date=new Date();
String df=DateFormat.getDateInstance().format(date);
System.out.println(df);
}
}
You can write that for example:
private Date TruncarFecha(Date fechaParametro) throws ParseException {
String fecha="";
DateFormat outputFormatter = new SimpleDateFormat("MM/dd/yyyy");
fecha =outputFormatter.format(fechaParametro);
return outputFormatter.parse(fecha);
}
The correct class to use for a date without time of day is LocalDate. LocalDate is a part of java.time, the modern Java date and time API.
So the best thing you can do is if you can modify the getStartDate method you are using to return a LocalDate:
DateTimeFormatter dateFormatter = DateTimeFormatter
.ofLocalizedDate(FormatStyle.SHORT)
.withLocale(Locale.forLanguageTag("en-IE"));
LocalDate d = eventList.get(0).getStartDate(); // We’re now getting a LocalDate using this method
String dateString = d.format(dateFormatter);
System.out.println(dateString);
Example output:
21/03/2012
If you cannot change the getStartDate, you may still be able to add a new method returning the type that we want. However, if you cannot afford to do that just now, convert the old-fashioned Date that you get (I assume java.util.Date):
d = eventList.get(0).getStartDate(); // I'm getting the old-fashioned Date using this method
LocalDate dateWithoutTime = d.toInstant()
.atZone(ZoneId.of("Asia/Kolkata"))
.toLocalDate();
Please insert the time zone that was assumed for the Date. You may use ZoneId.systemDefault() for the JVM’s time zone setting, only this setting can be changed at any time from other parts of your program or other programs running in the same JVM.
The java.util.Date class was what we were all using when this question was asked 6 years ago (no, not all; I was, and we were many). java.time came out a couple of years later and has replaced the old Date, Calendar, SimpleDateFormat and DateFormat. Recognizing that they were poorly designed. Furthermore, a Date despite its name cannot represent a date. It’s a point in time. What the other answers do is they round down the time to the start of the day (“midnight”) in the JVM’s default time zone. It doesn’t remove the time of day, only sets it, typically to 00:00. Change your default time zone — as I said, even another program running in the same JVM may do that at any time without notice — and everything will break (often).
Link: Oracle tutorial: Date Time explaining how to use java.time.
A bit of a fudge but you could use java.sql.Date. This only stored the date part and zero based time (midnight)
Calendar c = Calendar.getInstance();
c.set(Calendar.YEAR, 2011);
c.set(Calendar.MONTH, 11);
c.set(Calendar.DATE, 5);
java.sql.Date d = new java.sql.Date(c.getTimeInMillis());
System.out.println("date is " + d);
DateFormat df = new SimpleDateFormat("dd/MM/yyyy");
System.out.println("formatted date is " + df.format(d));
gives
date is 2011-12-05
formatted date is 05/12/2011
Or it might be worth creating your own date object which just contains dates and not times. This could wrap java.util.Date and ignore the time parts of it.
java.util.Date represents a date/time down to milliseconds. You don't have an option but to include a time with it. You could try zeroing out the time, but then timezones and daylight savings will come into play--and that can screw things up down the line (e.g. 21/03/2012 0:00 GMT is 20/03/2012 PDT).
What you might want is a java.sql.Date to represent only the date portion (though internally it still uses ms).
String substring(int startIndex, int endIndex)
In other words you know your string will be 10 characers long so you would do:
FinalDate = date.substring(0,9);
Another way to work out here is to use java.sql.Date as sql Date doesn't have time associated with it, whereas java.util.Date always have a timestamp.
Whats catching point here is java.sql.Date extends java.util.Date, therefore java.util.Date variable can be a reference to java.sql.Date(without time) and to java.util.Date of course(with timestamp).
In addtition to what #jseals has already said. I think the org.apache.commons.lang.time.DateUtils class is probably what you should be looking at.
It's method : truncate(Date date,int field) worked very well for me.
JavaDocs : https://commons.apache.org/proper/commons-lang/javadocs/api-2.6/org/apache/commons/lang/time/DateUtils.html#truncate(java.util.Date, int)
Since you needed to truncate all the time fields you can use :
DateUtils.truncate(new Date(),Calendar.DAY_OF_MONTH)
If you are using Java 8+, use java.time.LocalDate type instead.
LocalDate now = LocalDate.now();
System.out.println(now.toString());
The output:
2019-05-30
https://docs.oracle.com/javase/8/docs/api/java/time/LocalDate.html
You can also manually change the time part of date and format in "dd/mm/yyyy" pattern according to your requirement.
public static Date getZeroTimeDate(Date changeDate){
Date returnDate=new Date(changeDate.getTime()-(24*60*60*1000));
return returnDate;
}
If the return value is not working then check for the context parameter in web.xml.
eg.
<context-param>
<param-name>javax.faces.DATETIMECONVERTER_DEFAULT_TIMEZONE_IS_SYSTEM_TIMEZONE</param-name>
<param-value>true</param-value>
</context-param>
Don't try to make it hard just follow a simple way
date is a string where your date is saved
String s2=date.substring(0,date.length()-11);
now print the value of s2.
it will reduce your string length and you will get only date part.
Can't believe no one offered this shitty answer with all the rest of them. It's been deprecated for decades.
#SuppressWarnings("deprecation")
...
Date hitDate = new Date();
hitDate.setHours(0);
hitDate.setMinutes(0);
hitDate.setSeconds(0);
I went throe multiple posts about TimeZone and SimpleDateFormat on Google and Stack Overflow, but still do not get what I'm doing wrong.
I'm working on some legacy code, and there is a method parseDate, which gives wrong results.
I attached sample JUnit which I'm trying to use do investigate issue.
First method (testParseStrangeDate_IBM_IBM) uses IBM's implementation to format output of parseDate method.
Second formats output with Sun's implementation.
Using Sun's SimpleDateFormat gives us time different by an hour (which might be related to Day Light Savings). Setting default TimeZone to IBM's implementation fixes parseDate method (simply uncomment 3 lines in setupDefaultTZ method).
I am sure it's not a bug, but I am doing something wrong.
#Test
public void testParseStrangeDate_IBM_IBM() {
setupDefaultTZ();
Calendar date = parseDate("2010-03-14T02:25:00");
com.ibm.icu.text.SimpleDateFormat dateFormat = new com.ibm.icu.text.SimpleDateFormat(
"yyyy-MM-dd HH:mm:ss");
// PASSES:
assertEquals("2010-03-14 02:25:00", dateFormat.format(date.getTime()));
}
#Test
public void testParseStrangeDate_SUN_SUN() {
setupDefaultTZ();
Calendar date = parseDate("2010-03-14T02:25:00");
java.text.SimpleDateFormat dateFormat = new java.text.SimpleDateFormat(
"yyyy-MM-dd HH:mm:ss");
// FAILS:
assertEquals("2010-03-14 02:25:00", dateFormat.format(date.getTime()));
}
public static Calendar parseDate(String varDate) {
Calendar cal = null;
try {
// DOES NOT MAKE ANY DIFFERENCE:
// com.ibm.icu.text.SimpleDateFormat simpleDateFormat = new
// com.ibm.icu.text.SimpleDateFormat(
// "yyyy-MM-dd'T'HH:mm:ss");
java.text.SimpleDateFormat simpleDateFormat = new java.text.SimpleDateFormat(
"yyyy-MM-dd'T'HH:mm:ss", Locale.US);
Date date = simpleDateFormat.parse(varDate);
cal = GregorianCalendar.getInstance();
cal.setTimeInMillis(date.getTime());
System.out.println("CAL: [" + cal + "]");
} catch (ParseException pe) {
pe.printStackTrace();
}
return cal;
}
private void setupDefaultTZ() {
java.util.TimeZone timeZoneSun = java.util.TimeZone.getTimeZone("America/Chicago");
java.util.TimeZone.setDefault(timeZoneSun);
// UNCOMMENTING THIS ONE FIXES SUN PARSING ??
// com.ibm.icu.util.TimeZone timeZoneIbm = com.ibm.icu.util.TimeZone
// .getTimeZone("America/Chicago");
// com.ibm.icu.util.TimeZone.setDefault(timeZoneIbm);
Locale.setDefault(Locale.US);
}
The trouble is, you've specified a time which doesn't exist. The clocks go forward such that 2am becomes 3am - 2:25am never happens.
Now, there are various options for what could happen here. In Noda Time I believe we'd throw an exception (that's the plan anyway); I believe Joda Time (a far better Java API than Date/Calendar/SimpleDateFormat - you should consider migrating to it if you possibly can) will give you 3:25am, i.e. 25 minutes after the transition.
What would you want to happen when you're given a date/time combination which is impossible due to the DST transition? In this situation it's hard to know for sure what you mean by the "wrong" results. I would say your unit test is somewhat flawed - there is no possible time which should be formatted to that time.
My guess as to why the IBM time zone "works" is that it may use old time zone data, from before the US changed its DST transitions. Try using March 28th, which is when I think it would have been otherwise - you'll probably find the tests fail in the same way with the IBM zone, but not with the Sun one :) (As the Sun zone won't consider it a DST transition.)