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();
}
}
}
Related
This question already has answers here:
how to parse OffsetTime for format HHmmssZ
(2 answers)
Closed 1 year ago.
I am getting an parse error while parsing a date
java.text.ParseException: Unparseable date: "2021-06-17T05:49:41.174Z"
Unparseable date: "2021-06-17T05:49:41.174Z"
my code looks like this
private static String generateAndValidate(int count) {
Clock clock = Clock.systemUTC();
String clockTime=clock.instant().toString();
String result=clockTime;
SimpleDateFormat output = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSZ",Locale.ENGLISH);
try {
output.parse(clockTime);
} catch (ParseException e) {
System.out.println("process date parse error. Going for retry.");
}
return result;
}
Also tried hard coding the value here
SimpleDateFormat output = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSZ",Locale.ENGLISH);
try {
output.parse("2021-06-17T05:49:41.174Z");
} catch (ParseException e) {
System.out.println("process date parse error. Going for retry.");
}
What could be the problem?
EDIT: The reason for the failing of your code is in the answer given by #GS3!
My answer provides alternatives that are generally considered mroe up-to-date:
I would not recommend to use a java.text.SimpleDateFormat here because you are involving a very old and practically outdated API while you are receiving the time by the modern API utilizing a java.time.Clock.
A good move would be to use java.time.format.DateTimeFormatters for parsing, but I think you could even skip the clock and use OffsetDateTime.now(ZoneOffset.UTC).
However, this code definitely parses the String produced by your first lines:
public static void main(String[] args) {
// your first two lines
Clock clock = Clock.systemUTC();
String clockTime = clock.instant().toString();
// a hint to the problem
System.out.println(clockTime + " <--- 6 fractions of second");
// how to parse a String like that in plain java.time
OffsetDateTime odt = OffsetDateTime.parse(clockTime);
System.out.println(odt.format(
DateTimeFormatter.ISO_OFFSET_DATE_TIME
)
);
}
The output of that will look like the following (obviously having different values):
2021-06-17T06:34:55.490370Z <--- 6 fractions of second
2021-06-17T06:34:55.49037Z
The output that uses a DateTimeFormatter.ISO_OFFSET_DATE_TIME is just one option, you can still define your own pattern using a DateTimeFormatter.ofPattern(yourPatternString), a DateTimeFormatterBuilder in order to handle optional parts or one of the other built-in formatters.
If you just want to get the current moment and store it in a some datetime class, you can use the now() method the datetime classes in java.time have:
OffsetDateTime now = OffsetDateTime.now(ZoneOffset.UTC);
looks suitable here, but there's a ZonedDateTime, too.
Just have a look at java.time...
In SimpleDateFormat, Z represents a restricted subset of the RFC-822 time zone syntax. Instant::toString() provides a timestamp in the ISO-8601 format. You can fix this by using X instead of Z.
SimpleDateFormat output = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSX",Locale.ENGLISH);
I have a small block of code which parses response generation time from the response itself and turns it into a date for future purposes. It goes like this:
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSXXX");
Date responseTime = sdf.parse(RStime);
And it almost works like a charm. To be precise, it works 99.9% of the time, with the exception of one case: When the millisecond part is 000 then the Server doesn't append the .000 milliseconds at all, hence we have a problem.
Now, according to SimpleDateFormat docs if parsing fails, the function returns null. However, I probably misinterpreted it as it just throws an exception.
I am very new to Java and try-catch mechanisms, so could anyone please provide an elegant good-practice solution for handling such cases?
Thanks!
java.time
String rsTime = "2018-04-09T10:47:16.999-02:00";
OffsetDateTime responseTime = OffsetDateTime.parse(rsTime);
System.out.println("Parsed date and time: " + responseTime);
Output from this snippet is:
Parsed date and time: 2018-04-09T10:47:16.999-02:00
It works just as well for the version with the 000 milliseconds omitted:
String rsTime = "2018-04-09T10:47:16-02:00";
Parsed date and time: 2018-04-09T10:47:16-02:00
The classes you used, SimpleDateFormat and Date, are poorly designed and long outdated (the former in particular notoriously troublesome). So it is not only in this particular case I recommend using java.time, the modern Java date and time API, instead. However, the strings from your server are in ISO 8601 format, and OffsetDateTime and the other classes of java.time parse this format as their default, that is, without any explicit formatter, which already makes the task remarkably easier. Furthermore, in the standard the fractional seconds are optional, which is why both the variants of the string are parsed without any problems. OffsetDateTime also prints ISO 8601 back from it’s toString method, which is why in both cases a string identical to the parsed one is printed.
Only in case you indispensably need an old-fashioned Date object for a legacy API that you cannot change just now, convert like this:
Instant responseInstant = responseTime.toInstant();
Date oldfashionedDateObject = Date.from(responseInstant);
System.out.println("Converted to old-fashioned Date: " + oldfashionedDateObject);
Output on my computer in Europe/Copenhagen time zone is:
Converted to old-fashioned Date: Mon Apr 09 14:47:16 CEST 2018
Link: Oracle tutorial: Date Time explaining how to use java.time.
According to the SimpleDateFormat doc that you mentioned the parse method:
public Date parse(String text, ParsePosition pos)
Throws:
NullPointerException - if text or pos is null.
So one option is to catch that exception and do what you need inside the catch, for example:
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSXXX");
try {
Date responseTime = sdf.parse(RStime, position);
} catch (NullPointerException e) {
e.printStackTrace();
//... Do extra stuff if needed
}
Or the inherited method from DateFormat:
public Date parse(String source)
Throws:
ParseException - if the beginning of the specified string cannot be
parsed.
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSXXX");
try {
Date responseTime = sdf.parse(RStime);
} catch (ParseException e) {
e.printStackTrace();
//... Do extra stuff if needed
}
Is it actually an exceptional situation? If it is not then you probably shouldn't use exceptions in that case. In my opinion it is normal that time can end with .000ms. In this case you can check if the string contains . (dot) and if not append .000 to the end.
if(!RStime.contains(".")){
RStime+=".000";
}
Edit: I've forgot about time zone in the time String. You probably need something a little bit more complicated for that. Something like this should do it:
if(!RStime.contains(".")){
String firstPart = RStime.substring(0, 21);
String secondPart = RStime.substring(21);
RStime = firstPart + ".000" + secondPart;
}
You can check for a dot and then use the first or second format:
String timeString = "2018-04-09T10:47:16.999-02:00";
//String timeString = "2018-04-09T10:47:16-02:00";
String format = timeString.contains(".") ? "yyyy-MM-dd'T'HH:mm:ss.SSSXXX" : "yyyy-MM-dd'T'HH:mm:ssXXX";
Date responseTime = new SimpleDateFormat(format).parse(timeString);
System.out.println("responseTime: " + responseTime);
If you comment-out the first line and comment-in the second and run it again, it will both print out:
responseTime: Mon Apr 09 14:47:16 CEST 2018
By the way:
Java 7 (the version you use obviously) returns a java.text.ParseException: Unparseable date: "2018-04-09T10:47:16-02:00"
Optionals are supported since Java 8.
This code:
DateTimeParser[] parsers = { DateTimeFormat.forPattern("dd/MM/yyyy HH:mm:ss zzz").getParser(),
DateTimeFormat.forPattern("dd/MM/yyyy HH:mm:ss").getParser(), DateTimeFormat.forPattern("dd/MM/yyyy HH:mm").getParser(),
DateTimeFormat.forPattern("HH:mm").getParser() };
DateTimeFormatter formatter = new DateTimeFormatterBuilder().append(null, parsers).toFormatter();
Session session;
DateTime dTime = null;
Calendar calendar;
try{
if (completedTime != null && !completedTime.equalsIgnoreCase("")){
LocalDateTime jt = LocalDateTime.parse(completedTime, formatter);
LocalDateTime dt;
LocalDateTime retDate;
produces the error:
java.lang.IllegalArgumentException: Invalid format: "09/05/2015 04:00:00 GDT" is malformed at " GDT"
at the LocalDateTime jt = LocalDateTime.parse(completedTime, formatter); line
I can't for the life of me work out why it is failing. I am pretty sure it is something simple, but I haven't spotted it.
You may want to refer to this thread (or one of the many others like it). My best advice would be to try cutting to only one "z" in your parser.
You need to manually specify a mapping from timezone abbreviation to timezone. For example:
return new DateTimeFormatterBuilder()
.appendPattern("dd/MM/yyyy HH:mm:ss ")
.appendTimeZoneShortName(UK_TIMEZONE_SYMBOLS)
.toFormatter();
Here UK_TIMEZONE_SYMBOLS is a Map<String,DateTimeZone> which contains our view of timezone names (so BST is British summer time, not Bangladesh standard time)
Here's how we build ours:
public static Map<String, String> buildTimeZoneSymbolMap(Locale locale) {
Map<String, String> timeZoneSymbols = Maps.newLinkedHashMap();
for (String[] zoneInfo : DateFormatSymbols.getInstance(locale).getZoneStrings()) {
String timeZone = zoneInfo[0];
if (!timeZoneSymbols.containsKey(zoneInfo[2])) {
timeZoneSymbols.put(zoneInfo[2], timeZone);
}
if (zoneInfo[4] != null && !timeZoneSymbols.containsKey(zoneInfo[4])) {
timeZoneSymbols.put(zoneInfo[4], timeZone);
}
}
timeZoneSymbols.put("UTC", "GMT");
return timeZoneSymbols;
}
public static Map<String, DateTimeZone> buildDateTimeZoneSymbolMap(Locale locale) {
return Maps.transformValues(buildTimeZoneSymbolMap(locale), input -> DateTimeZone.forTimeZone(TimeZone.getTimeZone(input)));
}
public static final Map<String, DateTimeZone> UK_TIMEZONE_SYMBOLS = ImmutableMap.copyOf(buildDateTimeZoneSymbolMap(Locale.UK));
First thing to note:
What is "GDT"? The website http://www.timeanddate.com/time/zones/ does not yield an answer. So if it really exists and is not a typo then what is your locale? Remember that time zone names and abbreviations are highly localized.
Second: The count of pattern symbols "z" is okay - for classes like SimpleDateFormat etc. - see its documentation. Either four letters for the full name or less than four letters for the abbreviation:
General time zone: Time zones are interpreted as text if they have
names. Text: For formatting, if the number of pattern letters is 4 or
more, the full form is used; otherwise a short or abbreviated form is
used if available. For parsing, both forms are accepted, independent
of the number of pattern letters.
But you use Joda-Time. Its documentation clearly states:
Zone names: Time zone names ('z') cannot be parsed.
I have verified this non-support using the newest Joda-Time version 2.7 by following code:
DateTimeFormatter formatter = DateTimeFormat.forPattern("dd/MM/yyyy HH:mm:ss z").withLocale(Locale.GERMANY);
DateTime dt = formatter.parseDateTime("09/05/2015 04:00:00 MESZ");
System.out.println("Joda-Time: " + dt);
// Exception in thread "main" java.lang.IllegalArgumentException: Invalid format: "09/05/2015 04:00:00 MESZ" is malformed at "MESZ"
Of course, "MESZ" is correct and must be interpreted as Europe/Berlin in context of given german locale.
However, since version update (2.2) the same code set to Locale.US works for some timezones names like "EDT", "PST" etc., see also this commit. So we can finally say, the parsing support of Joda-Time for timezone names and abbreviations is best to say very limited. Once again, what is your Locale? If it is not US then I can understand why you get the exception. And you will also get an exception for the input "GDT" even if we consider it as valid due to the limited capabilities of Joda-Time-parser.
I'm trying to convert this string: 2014-01-01 00:00:00 to Joda DateTime
I have tried the following:
public static DateTime SimpleIso8601StringToDateTime(String date) {
DateTimeFormatter df = DateTimeFormat.forPattern(CONSTS_APP_GENERAL.SIMPLE_DATE_FORMAT);
return df.parseDateTime(date);
}
And also the following:
public static DateTime SimpleIso8601StringToDateTime(String date) {
DateTime dtDate = DateTime.parse(date, DateTimeFormat.forPattern(CONSTS_APP_GENERAL.SIMPLE_DATE_FORMAT));
return dtDate;
}
Where
public static final String SIMPLE_DATE_FORMAT = "yyyy-MM-dd HH:mm:ss.SSS";
However, using the debugger I get to the formatting line and then while trying to process it the program cursor never comes back.
I should mention that this is an Android project.
Any ideas what might be the problem?
It’s because 2014-01-01 00:00:00 doesn’t match the pattern yyyy-MM-dd HH:mm:ss.SSS—there’s no fractional part on the seconds in your input.
The result is that an unhandled exception gets raised—I’m not familiar with how Android handles those, the thread probably just dies unless you set a handler. But putting the parse() call inside a try block should let you recover.
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.)