This question already has answers here:
Why when year is less than 1884, it remove few milliseconds?
(2 answers)
Closed 3 years ago.
This is not a duplicate as some people think. It is about two standard Java classes for formatting dates that produce different strings for the same value of milliseconds since the epoch.
For values of milliseconds since the epoch that occur before some point in the year 1883, SimpleDateFormat and DateTimeFormatter will produce different results. For reasons I don't understand, DateTimeFormatter will produce strings that differ from what I expect by almost four minutes.
This is important because I am changing some code to use DateTimeFormatter instead of SimpleDateFormat. Our input is always milliseconds since the epoch, and I need the values to be the same after I change the code.
The previous code would create a Date from the milliseconds, then use SimpleDateFormat to format it.
The new code creates an Instant from the milliseconds, then a ZonedDateTime from the Instant, then a DateTimeFormatter to format it.
Here's a test I wrote using JUnit4 and Hamcrest. The test finds the milliseconds since the epoch for May 13, 15:41:25, for each year starting at 2019 and working backwards one year at a time.
For each year, it formats the milliseconds using SimpleDateFormat and DateTimeFormatter then compares the results.
#Test
public void testSimpleDateFormatVersusDateTimeFormatter() throws Exception {
String formatString = "EEE MMM dd HH:mm:ss zzz yyyy";
String timeZoneCode = "America/New_York";
ZoneId zoneId = ZoneId.of(timeZoneCode);
SimpleDateFormat simpleDateFormat = new SimpleDateFormat(formatString);
simpleDateFormat.setTimeZone(TimeZone.getTimeZone(timeZoneCode));
DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofPattern(formatString);
for (int year = 0; year < 200; year++) {
long millis = getMillisSinceEpoch(2019 - year, 5, 13, 15, 41, 25, timeZoneCode);
System.out.printf("%s%n", new Date(millis));
// Format using a DateTimeFormatter;
Instant instant = Instant.ofEpochMilli(millis);
ZonedDateTime zonedDateTime = ZonedDateTime.ofInstant(instant, zoneId);
String dateTimeFormatterString = dateTimeFormatter.format(zonedDateTime);
// Format using a SimpleDateFormat
Date date = new Date(millis);
String simpleDateFormatString = simpleDateFormat.format(date);
System.out.println("dateTimeFormatterString = " + dateTimeFormatterString);
System.out.println("simpleDateFormatString = " + simpleDateFormatString);
System.out.println();
assertThat(simpleDateFormatString, equalTo(dateTimeFormatterString));
}
}
private long getMillisSinceEpoch(int year, int month, int dayOfMonth, int hours, int minutes, int seconds, String timeZoneId) {
TimeZone timeZone = TimeZone.getTimeZone(timeZoneId);
Calendar calendar = Calendar.getInstance(timeZone);
calendar.set(Calendar.YEAR, year);
calendar.set(Calendar.MONTH, month-1);
calendar.set(Calendar.DAY_OF_MONTH, dayOfMonth);
calendar.set(Calendar.HOUR_OF_DAY, hours);
calendar.set(Calendar.MINUTE, minutes);
calendar.set(Calendar.SECOND, seconds);
return calendar.getTimeInMillis();
}
Running this you can see it passes for all years from 2019 back to 1884. So for any given year you see output like this:
Mon May 13 12:41:25 PST 1895
dateTimeFormatterString = Mon May 13 15:41:25 EST 1895
simpleDateFormatString = Mon May 13 15:41:25 EST 1895
But once it gets to 1883 it inexplicably fails:
Sun May 13 12:41:25 PST 1883
dateTimeFormatterString = Sun May 13 15:45:23 EST 1883
simpleDateFormatString = Sun May 13 15:41:25 EST 1883
java.lang.AssertionError:
Expected: "Sun May 13 15:45:23 EST 1883"
but: was "Sun May 13 15:41:25 EST 1883"```
The hours and seconds are obviously wrong.
By the way, if I change the time zone to "UTC", then the test passes.
According to https://www.timeanddate.com/time/change/usa/new-york?year=1883 (which was the first hit in a Google search for "1883 time adjustment"):
Nov 18, 1883 - Time Zone Change (LMT → EST)
When local standard time was about to reach
Sunday, November 18, 1883, 12:03:58 pm clocks were turned backward 0:03:58 hours to
Sunday, November 18, 1883, 12:00:00 noon local standard time instead.
3:58 matches the "almost four minutes" that you're seeing.
I haven't tested this, but I bet that if you iterate through months and days in addition to years, it occurs at that date.
See Also
Why when year is less than 1884, it remove few milliseconds?
Python pytz timezone conversion returns values that differ from timezone offset for different dates
Why is subtracting these two times (in 1927) giving a strange result? — a classic answered by Jon Skeet; not the same issue, but the same kind of issue
The Times Reports on "the Day of Two Noons"
Related
This Java code, given a date as a string, is supposed to print the epoch timestamp for the same date at the midnight for the CET zone (supposing I'm not in the same zone).
public static void main(String[] args) throws ParseException {
String dateStr = "1995-06-06";
SimpleDateFormat formatter = new SimpleDateFormat("yyyy-MM-dd");
formatter.setTimeZone(TimeZone.getTimeZone("CET"));
Date date = formatter.parse(dateStr);
Calendar c = new GregorianCalendar();
c.setTimeZone(TimeZone.getTimeZone("CET"));
c.setTime(date);
c.set(Calendar.HOUR_OF_DAY, 0);
c.set(Calendar.MINUTE, 0);
c.set(Calendar.SECOND, 0);
c.set(Calendar.MILLISECOND, 0);
System.out.println("Epoch timestamp = " + c.getTime().getTime());
}
If I run the above program I should get printed:
Epoch timestamp = 802389600000
And I can verify it's correct here:
https://www.epochconverter.com/timezones?q=802389600&tz=Europe%2FMalta
Now, that works for most of the dates. However, there are some bizarre dates like "1975-09-19", where it doesn't work. In fact, It generates 180313200000 as a timestamp, which gives 1am and not midnight:
https://www.epochconverter.com/timezones?q=180313200&tz=Europe%2FMalta
Can you explain why? What am I missing?
Time zone discrepancy
Your Java code uses CET, which is not really a time zone (for example because most of the areas where it’s used use CEST instead for most of the year). Java translates CET to Europe/Paris. France and Paris did not use summer time (DST) in 1975. It was reintroduced in March 1976.
Your link to the epoch converter specifies Malta time zone (Europe/Malta). Malta did use summer time in 1975: it was on CEST from 20 April to 21 September that year.
This explains the difference in your results.
In Java code
If you wanted Malta time:
String dateStr = "1975-09-19";
long epochTimestamp =
LocalDate
.parse(dateStr)
.atStartOfDay(ZoneId.of("Europe/Malta"))
.toInstant()
.toEpochMilli();
System.out.println("Epoch timestamp = " + epochTimestamp);
This prints:
Epoch timestamp = 180309600000
And the epoch converter that you linked to is happy to agree:
Conversion results (180309600)
180309600 converts to Friday September 19, 1975 00:00:00 (am) in
time zone Europe/Malta (CEST) The offset (difference to Greenwich
Time/GMT) is +02:00 or in seconds 7200. This date is in daylight
saving time.
In Java do use java.time, the modern Java date and time API, for your date and time work. It is so much nicer to work with compared to the old date and time classes like SimpleDateFormat, TimeZone, Date and Calendar. Also setting the hours, etc., to 0 is not the correct way to get the first moment of the day. There are cases where summer time begins at the start of the day, so the first moment of the day is 01:00:00. Java knows that, so the atStartOfDay method will give you the correct forst moment of the day in question.
And no matter if using outdated or modern classes always specify time zone in the region/city format, for example Europe/Paris or Europe/Malta. The three, four and five letter time zone abbreviations are often ambiguous and often not true time zones, so not to be relied on.
Links
Time Zone in Paris, Île-de-France, France
Time Zone in Valletta, Malta
Oracle tutorial: Date Time explaining how to use java.time.
There seems to be a difference concerning daylight saving time between your date examples.
If I use java.time (which should always be used since Java 8), I get results with different offsets:
"+02:00" for "1995-06-06" and
"+01:00" for "1975-09-19"
This is how I got the results:
public static void main(String[] args) {
// provide two sample dates
String workingDateStr = "1995-06-06";
String failingDateStr = "1975-09-19";
// and a formatter that parses the format
DateTimeFormatter dtf = DateTimeFormatter.ofPattern("yyyy-MM-dd");
// then parse them to date objects that don't know about time or zone
LocalDate workingDate = LocalDate.parse(workingDateStr, dtf);
LocalDate failingDate = LocalDate.parse(failingDateStr, dtf);
/*
* then create an objects that are aware of time and zone
* by using the parsed dates, adding a time of 00:00:00 and a zone
*/
ZonedDateTime workingZdt = ZonedDateTime.of(workingDate, LocalTime.MIN, ZoneId.of("CET"));
ZonedDateTime failingZdt = ZonedDateTime.of(failingDate, LocalTime.MIN, ZoneId.of("CET"));
// finally, print different representations of the results
System.out.println(workingZdt + " ——> " + workingZdt.toInstant().toEpochMilli());
System.out.println(failingZdt + " ——> " + failingZdt.toInstant().toEpochMilli());
}
Output:
1995-06-06T00:00+02:00[CET] ——> 802389600000
1975-09-19T00:00+01:00[CET] ——> 180313200000
That means you might be better off using specific offsets instead of zones.
This issue could be due to the timing of the introduction of Daylight Saving Time in Malta, have a look at the following code and its output:
public static void main(String[] args) {
// provide two sample dates
String failingDateStr = "1975-09-19";
// and a formatter that parses the format
DateTimeFormatter dtf = DateTimeFormatter.ofPattern("yyyy-MM-dd");
// then parse them to date objects that don't know about time or zone
LocalDate failingDate = LocalDate.parse(failingDateStr, dtf);
/*
* then create an objects that are aware of time and zone
* by using the parsed dates, adding a time of 00:00:00 and a zone
*/
ZonedDateTime failingZdt = ZonedDateTime.of(failingDate, LocalTime.MIN, ZoneId.of("CET"));
// add some years to 1975 and...
for (int year = 0; year < 4; year++) {
// ... print the different representations of the result
System.out.println(failingZdt.plusYears(year) + " ——> "
+ failingZdt.plusYears(year).toInstant().toEpochMilli());
}
}
Output:
1975-09-19T00:00+01:00[CET] ——> 180313200000
1976-09-19T00:00+01:00[CET] ——> 211935600000
1977-09-19T00:00+02:00[CET] ——> 243468000000
1978-09-19T00:00+02:00[CET] ——> 275004000000
This output indicates an introduction in 1977... Is that correct?
I have date formats as: EEE, dd MMM yyyy HH:mm:ss Z
For ex.,
Date 1 : Mon Sep 10 08:32:58 GMT 2018
Date 2 : Tue Sep 11 03:56:10 GMT 2018
I need date difference as 1 in above case, but I am getting value as 0 if I use joda date time or manually converting date to milliseconds.
For reference : http://www.mkyong.com/java/how-to-calculate-date-time-difference-in-java/
Any leads will be helpful.
Example :
Date date1 = new Date("Mon Sep 10 08:32:58 GMT 2018");
Date date2 = new Date("Tue Sep 11 03:56:10 GMT 2018");
DateTime start = new DateTime(date1 );
DateTime end = new DateTime(date2);
int days = Days.daysBetween(start, end).getDays();
System.out.println("Date difference: " + days);
Output: Date difference: 0
Joda-Time counts only whole days, in other words, truncates the difference to a whole number. So with a little over 19 hours between your values it counts as 0 days. If you want to ignore the time part of the dates, convert to LocalDate first:
int days = Days.daysBetween(start.toLocalDate(), end.toLocalDate()).getDays();
(Thanks for providing the concrete code yourself in a comment. Since you said it worked, I thought it deserved to be an answer.)
As mentioned in previous comments, Joda-Time counts whole days and rounds down. Therefore you'll need to skip the time when comparing. Something like this will work, using Java.time comparing the dates:
Date date1 = new Date("Mon Sep 10 08:32:58 GMT 2018");
Date date2 = new Date("Tue Sep 11 03:56:10 GMT 2018");
LocalDate start = date1.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();
LocalDate end = date2.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();
long between = ChronoUnit.DAYS.between(start, end);
System.out.println("Date difference: " + between);
int year = Integer.parseInt(sTransDateTime2.substring(0, 4));
int month = (Integer.parseInt(sTransDateTime2.substring(4, 6)) - 1);
int day = Integer.parseInt(sTransDateTime2.substring(6, 8));
int hour = Integer.parseInt(sTransDateTime2.substring(8, 10));
int minute = Integer.parseInt(sTransDateTime2.substring(10, 12));
int second = Integer.parseInt(sTransDateTime2.substring(12));
System.out.println("year=" + year + "| month= " + month + "| day=" + day);
DateFormat df = new SimpleDateFormat("mm/dd/yyyy");
Calendar calConvert = Calendar.getInstance();
calConvert.set(year, month, day, hour, minute, second);
sTransDateTime2 = Long.toString(calConvert.getTimeInMillis() / 1000);
System.out.println("debug date: " + sTransDateTime2);
my date time is year=2017| month= 7| day=28| hour= 17| minute=0,
After convert to milliseconds it become 1501232400.
The result of date is correct, will be 28 Jul 2017, but time become 9.00pm.
Any wrong on my coding?
Thanks
stop learning the old broken java.date and move into the java.time
LocalDateTime myldt = LocalDateTime.of(2017, 7, 28, 17, 0);
System.out.println(myldt);
System.out.println(myldt.atZone(ZoneId.systemDefault()).toInstant().toEpochMilli());
It looks like the conversion to milliseconds is being done in one TimeZone, but the system on which the milliseconds are converted to date is in a different timezone.
28th July, 2017 17:00:00 gives seconds from epoch as 1501232400 when in UTC+08:00 timezone, but these seconds from epoch give back 28th July, 2017 21:00:00 in UTC+12:00 timezone.
To illustrate the above, I have explicitly set the timezone to UTC+8:00 when calculating the milliseconds. (I have set my system timezone to UTC+12:00 to show the output)
System.out.println("year=" + year + "| month= " + month + "| day=" + day);
Calendar calConvert = Calendar.getInstance();
calConvert.setTimeZone(TimeZone.getTimeZone("GMT+8:00"));
calConvert.set(year, month, day, hour, minute, second);
sTransDateTime2 = Long.toString(calConvert.getTimeInMillis() / 1000);
System.out.println("debug date: " + sTransDateTime2);
System.out.println(new Date(calConvert.getTimeInMillis()));
This gives me the output as below:
year=2017| month= 6| day=28
debug date: 1501232400
Fri Jul 28 21:00:00 NZST 2017
Please note that Date always prints the date in local timezone. So, it has converted the milliseconds as per local timezone and the time changes to 21:00.
Now I format this date to make sure that I get the output back in UTC+08:00 only, whatever be the system timezone.
Date dt = calConvert.getTime();
DateFormat formatter= new SimpleDateFormat("MM/dd/yyyy HH:mm:ss");
formatter.setTimeZone(TimeZone.getTimeZone("GMT+8:00"));
System.out.println(formatter.format(dt));
Now I get the output as : 07/28/2017 17:00:00 instead of the earlier date with 21:00 as time.
So, the conclusion is that you need to format the date to be displayed in a specific timezone, if you want to avoid it picking up the default timezone of the system on which it is displayed.
To avoid all the cumbersome code and confusing issues, as suggested in the other answer, go for the java.time API. java.time is available from JDK 8. As you are using JDK 6, you can use the ThreeTen Backport. Just to illustrate the ease with which things could be done with java.time , the following does the same what your code does , but in a concise and easily understandable way:
ZonedDateTime zdt = ZonedDateTime.of(LocalDate.of(year, month, day),
LocalTime.of(hour, minute,second), ZoneId.of("Asia/Macau"));
long secondsFromEpoch = zdt.toEpochSecond();
//To convert back
ZonedDateTime zdtBack = Instant.ofEpochSecond(secondsFromEpoch)
.atZone(ZoneId.of("Asia/Macau"));
System.out.println(zdtBack);
This question already has answers here:
How to create a Java Date object of midnight today and midnight tomorrow?
(20 answers)
Closed 6 years ago.
I want to round a java.util.Date object to the end of the day, e.g. rounding 2016-04-21T10:28:18.109Z to 2016-04-22T00:00:00.000Z.
I saw Java Date rounding, but wasn't able to find something compareable for the end of the day. It also is not the same as how to create a Java Date object of midnight today and midnight tomorrow?, because I don't want to create a new Date (midnight today or tomorrow), but the next midnight based on any given date.
The DateUtils.ceiling serves your purpose. Pass Calendar.DATE for field value.
Given the documentation of DateUtils, I'm not sure I'd trust it with this.
Assuming you're only interested in a UTC day, you can take advantage of the fact that the Unix epoch is on a date boundary:
public static Date roundUpUtcDate(Date date) {
long millisPerDay = TimeUnit.DAYS.toMillis(1);
long inputMillis = date.getTime();
long daysRoundedUp = (inputMillis + (millisPerDay - 1)) / millisPerDay;
return new Date(daysRoundedUp * millisPerDay);
}
I would strongly urge you to move to the java.time API if you possibly can though.
Traditional way
#Test
public void testDateRound() throws ParseException {
Date date = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS").parse("2016-04-21T10:28:18.109Z");
System.out.println(date);
Calendar cl = Calendar.getInstance();
cl.setTime(date);
cl.set(Calendar.HOUR_OF_DAY, 23);
cl.set(Calendar.MINUTE, 59);
cl.set(Calendar.SECOND, 59);
cl.set(Calendar.MILLISECOND, 999);
System.out.println(cl.getTime());
cl.add(Calendar.MILLISECOND, 1);
System.out.println(cl.getTime());
}
Output
Thu Apr 21 10:28:18 GMT+03:00 2016
Thu Apr 21 23:59:59 GMT+03:00 2016
Fri Apr 22 00:00:00 GMT+03:00 2016
I am using an API to get a weather forecast up until a particular date in Java.
The requirement for passing a date as a URL parameter is that it must be in "YYYY-MM-DD'T'HH:MM:SS" format. I get input in this format from the user, then get the current system date, and then loop until the desired date. The problem lies in converting the input date string into the date format, incrementing it by one day, and then converting it back to the string format for URL parameter.
I am using the following code to do this but it is giving me incorrect results:
formatter = new SimpleDateFormat("YYYY-MM-DD'T'HH:MM:SS");
Date date1 = formatter.parse(inputtime);
System.out.println(date1);
Calendar c1 = Calendar.getInstance();
c1.setTime(date1);
c1.add(Calendar.DAY_OF_MONTH, 1); // number of days to add
inputtime = formatter.format(c1.getTime()); // dt is now the new date
System.out.println(c1.getTime());
System.out.println(inputtime);
inputtime is the input by the user. If I give "2014-04-12T00:00:00" as inputtime, date1 is then "Sun Dec 29 00:00:00 PKT 2013", c1.getTime() returns "Mon Dec 30 00:00:00 PKT 2013" and inputtime becomes then "2014-12-364T00:12:00" according to the above code block.
How can this logic error be corrected?
You should consider SimpleDateFormat date and time patterns: link
For example, something like this:
formatter = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");
Have a try to change your date pattern from
new SimpleDateFormat("YYYY-MM-DD'T'HH:MM:SS");
to
new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");
Letter Date or Time Component Presentation Examples
y Year Year 1996; 96
M Month in year Month July; Jul; 07
D Day in year Number 189
d Day in month Number 10
h Hour in am/pm (1-12) Number 12
m Minute in hour Number 30
s Second in minute Number 55
S Millisecond Number 978
The java.util.Date and .Calendar classes bundled with Java are notoriously troublesome. Avoid them.
That format is defined by the ISO 8601 standard. The Joda-Time library follows that standard's formats as a default for both parsing and generating strings. So does the new java.time package in Java 8.
Your string omits a time zone offset. So, you need to know and specify the time zone intended by that string. Perhaps the time zone is UTC meaning a time zone offset of zero.
A day is not always 24 hours. If you meant 24 hours rather than 1 day, call the method plusHours( 24 ).
Here is example code in Joda-Time 2.3.
String input = "2014-01-02T03:04:05";
DateTimeZone timeZone = DateTimeZone.UTC;
DateTime dateTime = new DateTime( input, timeZone );
DateTime tomorrow = dateTime.plusDays( 1 );
String outputWithOffset = tomorrow.toString();
String output = ISODateTimeFormat.dateHourMinuteSecond().print( tomorrow );