I expected this to throw an exception because the 1st of February 2016 is not a Friday:
final DateTimeFormatter formatter = DateTimeFormat.forPattern("EEEE, d MMMM yyyy");
final DateTime date = formatter.parseDateTime("Friday, 1 February 2016");
System.out.println(formatter.print(date));
Instead, it printed out Friday, 5 February 2016. What am I missing here?
It's explained in the doc (http://www.joda.org/joda-time/apidocs/org/joda/time/format/DateTimeFormatter.html)
Parsing builds up the resultant instant by 'setting' the value of each parsed field from largest to smallest onto an initial instant, typically 1970-01-01T00:00Z. This design means that day-of-month is set before day-of-week. As such, if both the day-of-month and day-of-week are parsed, and the day-of-week is incorrect, then the day-of-week overrides the day-of-month. This has a side effect if the input is not consistent.
Related
I have some strings in Java that come in the format: Day Month Year Hour:Minute:Second
7 Jan 2010 23:00:00.000
4 Feb 2010 17:40:00.000
What is the easiest way to parse this string and convert the values to their resulting Julian Dates? I am reading in these strings from Excel so they are not objects with any sort of conversion/formatting utilities (just raw strings). Is there an easy library or function to call to convert these, or would I have to manually write a parser? Thanks
java.time
Sure, Java has got a parser for date and time built-in, the DateTimeFormatter class (named so because it can also format date and time back to strings). And a number of classes that can utilize it for producing objects of themselves. In your case you need the LocalDateTime class. A LocalDateTime is a date and time of day without time zone or offset from UTC, so appropriate for holding the data from your string.
This formatter s good for your string:
private static final DateTimeFormatter FORMATTER
= DateTimeFormatter.ofPattern("d MMM uuuu HH:mm:ss.SSS", Locale.ENGLISH);
Edit: You wrote in a comment:
Plugging in Jan 7 2010 hour 23 into this calculator:
aavso.org/jd-calculator gives
back 2455204.45833. Would this be the exact Julian Date? I believe
your solution was giving the Day instead of Date decimal value
Yes, that’s exactly true. The modified code to get the julian date including the fraction is:
String source = "7 Jan 2010 23:00:00.000";
LocalDateTime ldt = LocalDateTime.parse(source, FORMATTER);
// Subtract half a day to compensate for the
// fact that the Julian day begins at noon
LocalDateTime dateToUseForJulianDay = ldt.minusHours(12);
long julianDayNumber = dateToUseForJulianDay.getLong(JulianFields.JULIAN_DAY);
double juianDateFraction = (double) dateToUseForJulianDay.getLong(ChronoField.NANO_OF_DAY)
/ (double) Duration.ofDays(1).toNanos();
double julianDate = julianDayNumber + juianDateFraction;
System.out.println("Julian date: " + julianDate);
And the output is in this example:
Julian date: 2455204.4583333335
It agrees very nicely with thee result you quote from the online calculator.
The Julian day number is the day number since January 1, 4713 BC. The Julian day starts at noon, which Java does not take into account, so as a hack I have subtracted 12 hours to compensate and get the correct day for all times of day. Since the getLong() method only gets the Julian day number as a whole number, I need to find the fraction separately. It’s a matter of dividing the nanosecond of the day by the total number of nanoseconds in a day. From the original date and time we would have needed the number of nanos since 12 noon; but since I have already subtracted 12 hours, the nanosecond of the day, since 0:00 midnight, is the number we need.
Further link: Julian day on Wikipedia
My library Time4J supports Julian Dates out of the box.
ChronoFormatter<PlainTimestamp> f =
ChronoFormatter.ofTimestampPattern(
"d MMM uuuu HH:mm:ss.SSS", PatternType.CLDR, Locale.ENGLISH);
Moment j2000 = f.parse("7 Jan 2010 23:00:00.000").atUTC(); // are your timestamps really UTC?
// eventually also: ".in(Timezone.ofSystem());"
System.out.println(JulianDay.ofSimplifiedTime(j2000)); // programmer's standard
// JD(POSIX)2455204.4583333335
System.out.println(JulianDay.ofEphemerisTime(j2000)); // astronomical definition
// JD(TT)2455204.459099352
Advantages:
No complex calculation of your owns.
Support for the astronomical definition on the time scale TT.
Explicit display of time zone dependencies (whatever you choose).
I am learning java, trying to build a tool to convert a specific time from timezone A to timezone B based on user input (input of the time, timezone A, and timezone B). This is about the part where the tool gathers a time in a specific format to convert it into a ZonedDateTime object.
import java.time.ZonedDateTime;
import java.time.format.DateTimeFormatter;
import java.util.*;
public static String fullTime;
public static DateTimeFormatter formatter = DateTimeFormatter.ofPattern("HH:mm a");
public static ZonedDateTime newTime;
public static void getHourAndMinutes(){
System.out.print("Please type in the time you have in mind in format hh:mm am/pm\n");
Scanner in = new Scanner(System.in);
fullTime = in.nextLine();
System.out.println(fullTime);
newTime = ZonedDateTime.parse(fullTime, formatter);
I have tried to enter the time in formats like 10:30PM, 10:30 PM, 10:30pm, 10:30 pm, 10:30p, 10:30 p, all of these entries has caused exception error to be thrown, I'm getting errors like this one
Exception in thread "main" java.time.format.DateTimeParseException: Text '10:30 pm' could not be parsed at index 6
Any idea what I might be doing wrong? Thanks!
Since the user entering input is just representing time you need to parse it into LocalTime, and the other mistake is you are using the wrong pattern, H is hour-of-day (0-23); you need h in DateTimeFormatter
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("hh:mm a");
LocalTime localTime = LocalTime.parse("10:30 PM",formatter);
After parsing the input into LocalTime you can convert it into ZonedDateTime. But you must specify a date (LocalDate) as well as the time and the zone. Your code in the Question had only the time-of-day, and lacked the date and zone needed to instantiate a ZonedDateTime.
ZonedDateTime dateTime = localTime.atDate(LocalDate.now()).atZone(ZoneId.systemDefault());
And then you can convert it into another zone using withZoneSameInstant
ZonedDateTime result = dateTime.withZoneSameInstant(ZoneId.of("America/New_York));
Any idea what I might be doing wrong? Thanks!
A number of things, I am afraid.
For a ZonedDateTime you need a date and a time and a time zone. For parsing a string containing only time of day into a ZonedDateTime you would have needed to supply a default date and a default time zone. However, instead I would parse into a LocalTime, which is exactly a time if day without date and without time zone. After parsing you may convert. You need to decide a date for your conversion since your time zone A (and B too) probably uses a different UTC offset on different dates because of summer time (DST) and/or historic and/or future changes in their base UTC offset.
You need to provide a locale for your formatter to tell it in which language to assume AM and PM. For example DateTimeFormatter.ofPattern("HH:mm a", Locale.ENGLISH).
You need to enter AM or PM in the correct case (upper or lower case) for the locale you specified.
For parsing a string with hour within AM or PM from 01 through 12 you need to use lower case hh in the format pattern string. Not upper case HH, which would be for hour of day from 00 through 23.
This question already has answers here:
SimpleDateFormat producing wrong date time when parsing "YYYY-MM-dd HH:mm"
(5 answers)
Closed 4 years ago.
I want to convert 2018-02-21 15:47:35 UTC to epoch UTC form. How do we do it? I am currently in PST.
SimpleDateFormat df = new SimpleDateFormat("YYYY-MM-DD HH:MM:SS");
df.setTimeZone(TimeZone.getTimeZone("UTC"));
date = df.parse(dateString).getTime();
The code above should return the number of milliseconds since January 1, 1970, 00:00:00 GMT, but I'm getting an incorrect value.
The only problem with your code is DateFormat
please check.
https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html
String dateString = "2018-02-21 15:47:35";
SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
df.setTimeZone(TimeZone.getTimeZone("UTC"));
Date date = df.parse(dateString);
long time = date.getTime();
System.out.println(time);
System.out.println(new Date(time));
System.out.println(date);
I'm in PKT so output would differ...
1519228055000
Wed Feb 21 20:47:35 PKT 2018
Wed Feb 21 20:47:35 PKT 2018
Expected: 2018-02-21 15:47:35 UTC is equivalent to 1 519 228 055 000 milliseconds since the epoch of January 1, 1970 at 0:00 UTC.
Observed: Your code in the question gives 1 514 818 800 035. So it’s 4 409 254 965 milliseconds off, a little over 51 days.
The solution:
DateTimeFormatter dtf = DateTimeFormatter.ofPattern("uuuu-MM-dd HH:mm:ss");
date = LocalDateTime.parse("2018-02-21 15:47:35", dtf)
.atOffset(ZoneOffset.UTC)
.toInstant()
.toEpochMilli();
This gives the correct 1 519 228 055 000.
What went wrong?
One of the many troublesome traits of SimpleDateFormat is that with its default settings, if you specify an incorrect format pattern string, it will very often give you an incorrect result and pretend all is well. The modern Java date and time API that I am using in my snippet, is trying somewhat harder to figure out when the pattern doesn’t make sense and tell you it’s wrong somehow. As an example, let’s try your format pattern with the modern DateTimeFormatter:
final DateTimeFormatter dtf = DateTimeFormatter.ofPattern("YYYY-MM-DD HH:MM:SS");
LocalDateTime.parse(dateString, dtf);
This will throw a java.time.format.DateTimeParseException: Text '2018-02-21 15:47:35' could not be parsed at index 14. Index 14 is where 47 is in the string, it was supposed to be the minutes. Apparently 47 doesn’t match MM in the format. If you haven’t figured out yet, check the documentation. It says that uppercase M is for “month-of-year”. So what the formatter is trying to tell you is there are not 47 months in a year. In the documentation you will also find lowercase m for “minute-of-hour”. As you correct the case of the letters in the format pattern string, you will receive other exceptions until you end up with either yyyy-MM-dd HH:mm:ss or uuuu-MM-dd HH:mm:ss (lowercase yyyy is year or era while uuuu is a signed year, both work for years after year 0).
Links
Oracle tutorial: Date Time explaining how to use java.time.
DateTimeFormatter documentation spelling out the uppercase and lowercase letters of format pattern strings.
Also can be done via java8 time library:
String dateString = "2018-02-21 15:47:35";
DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss", Locale.ENGLISH);
dateTimeFormatter.withZone(ZoneId.of("UTC"));
LocalDateTime parsedDateTime = LocalDateTime.from(dateTimeFormatter.parse(dateString));
ZonedDateTime timeAtYourZone = parsedDateTime.atZone(ZoneId.systemDefault());
System.out.println(timeAtYourZone.toInstant().toEpochMilli());
System.out.println(timeAtYourZone);
Your pattern must be yyyy-MM-dd HH:mm:ss, as the other answers told you:
SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
I just want to add some more details.
First of all, take a look at the patterns description in the javadoc: https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html
Note that a lowercase y is not the same as the uppercase Y (lowercase is the year, while uppercase is the week year - 2 different fields with completely different definitions)
Also note that uppercase D is the day of the year, while the day of the month (which is what you want) is the lowercase d. And uppercase M is the month, while lowercase m is the minute of hour.
And uppercase S is the milliseconds field, while the seconds are represented by lowercase s.
And SimpleDateFormat's design doesn't help: the class simply tries to parse the string, even if the month field (MM) appears twice in your pattern, while the minutes field doesn't appear (and it's set to a default value of zero - all behind the scenes, without any warning, no indication of error at all).
Conclusion: always read the docs :-)
For Java 8 or higher, consider using the new date API, which is much better because it doesn't have all these behind-the-scenes stuff:
DateTimeFormatter fmt = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")
.withZone(ZoneOffset.UTC);
long epochMilli = Instant.from(fmt.parse("2018-02-21 15:47:35")).toEpochMilli();
This API will also throw an exception if you use a pattern like YYYY-MM-DD HH:MM:SS, because it will try to parse the minutes value 47 as a month (because uppercase MM will be in the respective position), and 47 is not a valid month.
Why this code
DateTimeFormatter SENT_DATE_FORMATTER = DateTimeFormatter.ofPattern("E, d MMM YYYY HH:mm:ss Z", Locale.US);
ZonedDateTime now = ZonedDateTime.now();
String dateStr = now.format(SENT_DATE_FORMATTER);
System.out.println(dateStr);
ZonedDateTime zoned = ZonedDateTime.parse(dateStr, SENT_DATE_FORMATTER);
Prints the correct date on the sysout line but throws a DateTimeParseException (Unable to obtain ZonedDateTime from TemporalAccessor) on the parse line?
Capitalized Y stands for week-based-year, see javadoc. In order to make the parser working you rather need to change it to year (u) or year-of-era (y). Then the parser can create a date out of calendar year, month (M) and day-of-month (d). Keep in mind that the week-based-year can relate to previous or next calendar year, not the actual one if your month and day-of-month are near the start or end of calendar year. Therefore it is not possible to just equalize the week-based-year to the calendar year! And without a precisely defined calendar year it is not possible to form a date.
Otherwise, if you had the week-of-week-based-year (w) in your pattern, too, then your parser would be able to understand the input because week-based-year (Y), week-of-week-based-year (w) and day-of-week (E) would also make an interpretable combination for a date.
Note however, that all given details in the input matching your pattern must be consistent (for example 2015-08-31 is Monday and not Tuesday) otherwise the parser will complain again (at least in strict mode).
I have a date that's in the form of:
Wed Aug 17 2011 09:57:09 GMT+0100 (BST)
and have a filter that takes a time in a certain format. The problem seems to be the time zone on the end, none of the format strings I'm putting in the filter seem to work for this type of date format.
For example,
Wed Aug 17 2011 09:57:09 GMT+0100 (BST)
EEE MMM dd yyyy HH:mm:ss zZ?
The time zone part of this, keeps throwing an error.
Can anyone tell me what the correct format to parse the time zones on these dates is?
"z" needs a colon between hours and minutes. "Z" is only +/-HHMM (i.e. no "GMT" prefix).
One way to parse it is: EEE MMM dd yyyy HH:mm:ss 'GMT'Z. The "BST" bit is ignored, and it's based on assumption that there's always "GMT" before offset.
I would parse out and interpret the time zone information separately, then use that to construct the Date/Calendar object in the proper time zone.
The following code seems to work well enough with your example:
String source = "Wed Aug 17 2011 09:57:09 GMT+0100 (BST)";
String tzid = "GMT" + source.substring(28, 31)
+ ":" + source.substring(31, 33);
TimeZone tz = TimeZone.getTimeZone(tzid);
// if (tz == null) ?
SimpleDateFormat f = new SimpleDateFormat("EEE MMM dd yyyy HH:mm:ss");
f.setTimeZone(tz);
Date date = f.parse(source);
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
System.out.println(date);
Prints "Wed Aug 17 08:57:09 UTC 2011".
A more sophisticated approach would be to use regex to extract individual parts ("+/-", "hh" and "mm") of the time zone offset.
Alternatively, you can attempt to discern the 3-letter time zone id (the string in between ( and )), and use the corresponding Java TimeZone if it exists.
In your particular example, though, "BST" resolves to Bangladesh Time which is GMT+0600 so you're better off with the numeric offset. "BST" here should probably be taken as British Summer Time (GMT+0100). This can be important because numeric offsets do not indicate the use of daylight savings time, which can be in effect depending on the date.
A more heuristic routine could take this into account and attempt to resolve the name first, but verify that the GMT offsets match, and fallback on the simple "GMT+hh:mm" timezones otherwise.
If you can not find a pattern matching your use case, try:
try{
new Date("Wed Aug 17 2011 09:57:09 GMT+0100 (BST)")
}catch(Exception e)
{
// Parse exception
}