I wrote a java utility function to convert yyyy/mm/dd as follows
public static long gettimestamp(String dateString) {
SimpleDateFormat df = new SimpleDateFormat("yyyy/mm/dd");
Date date;
try {
date = df.parse(dateString);
} catch (java.text.ParseException e) {
return 0;
}
long epoch = date.getTime();
return (epoch / 1000);
}
On passing 2014/06/12 - it gives 1389465360 (=Jan 11, 2014) which is wrong. Am I passing format in wrong way ?
You should uppercase the M. Lowercase m stands for minutes, while uppercase stands for month. Here's the documentation.
LocalDate.parse("2014/06/12".replace("/" , "-"))
.atStartOfDay(ZoneId.of("America/Montreal"))
.toEpochSecond()
The Answer by Cornelissen is correct, your formatting pattern is incorrect.
You fail to consider time zone. Your goal is getting a count of the seconds since the epoch of the start of 1970. That involves a time-of-day, when the day starts. The start of day varies around the globe by zone. A new day dawns earlier in Paris France than Montréal Québec.
Furthermore, you are using troublesome old legacy date-time classes now supplanted by the java.time classes.
The LocalDate class represents a date-only value without time-of-day and without time zone.
DateTimeFormatter f = DateTimeFormatter.ofPattern( "uuuu/mm/dd" );
LocalDate ld = LocalDate.parse( "2014/06/12" , f );
Alternatively, you could transform your input String to comply with standard ISO 8601 format by replacing the slash character with hyphen character. The java.time classes use ISO 8601 formats by default when parsing/generating strings.
Adjust that LocalDate into a specific time zone intended by the context of your date. We get a ZonedDateTime object.
Let java.time determine the start time of the day. Do not hard-code 00:00:00. In some time zones anomalies such as Daylight Saving Time (DST) may result in a day starting at a time such as 01:00:00.
ZoneId z = ZoneId.of( "America/Montreal" ); // Or ZoneOffset.UTC if you meant UTC (GMT).
ZonedDateTime zdt = ld.atStartOfDay( z );
You may interrogate for the number of whole seconds since the epoch of 1970-01-01T00:00:00Z.
long secondsSinceEpoch = zdt.toEpochSecond();
1402545600
By the way, I strongly recommend against tracking date-time values as a count-since-epoch. Hard to read, hard to debug, prone to errors, leads to ambiguity over different epochs used by different software systems (at least a couple dozen epochs have been used).
Case in point: Your expected value of 1389465360 makes no sense to me. Using ZoneOffset.UTC I get the start of that date as 1402531200. Your expected value results in a time-of-day of 18:36 on January 11, 2014 when interpreted as a count of whole seconds since start of 1970 in UTC.
System.out.println ( Instant.ofEpochSecond ( 1_389_465_360L ).toString () );
2014-01-11T18:36:00Z
The java.time framework is built into Java 8 and later. These classes supplant the old troublesome date-time classes such as java.util.Date, .Calendar, & java.text.SimpleDateFormat.
The Joda-Time project, now in maintenance mode, advises migration to java.time.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations.
Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport and further adapted to Android in ThreeTenABP (see How to use…).
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.
