Java/Kotlin String Date to milliseconds conversion

Question

I am trying to figure out how the https://www.epochconverter.com/ website converts a String date to milliseconds and then replicate the same logic in Java/Kotlin code. But I am unable to come up with an equivalent Java/Kotlin code.

For example, for the date "1979/12/31 23:30:00" is converted to 315552600000 milliseconds by https://www.epochconverter.com/

but my below kotlin code outputs 315531000000 instead of 315552600000.

import java.text.SimpleDateFormat
import java.time.*
import java.time.format.DateTimeFormatter
import java.util.*


fun main(){ 
        
    val startTime = "1979/12/31 23:30:00"
    val dateFormat = SimpleDateFormat("yyyy/MM/dd HH:mm:ss")
    val startTimeInMillis = dateFormat.parse(startTime).time.toString()
    println(startTimeInMillis)
  
}

Is there anything missing in above code that is causing different results ?

I strongly recommend you don’t use `SimpleDateFormat` and friends. The `SimpleDateFormat` class is notoriously troublesome, and related classes like `Date` are poorly designed too. Fortunately they are all long outdated. Use `LocalDateTime`, `ZoneId`, `ZonedDateTime` and `DateTimeFormatter`, all from [java.time, the modern Java date and time API](https://docs.oracle.com/javase/tutorial/datetime/index.html). The classes you are already importing. — Ole V.V., Dec 14 '22 at 03:57
The result you report, 315531000000, agrees with 1979/12/31 23:30:00 UTC. So apparently your device or at least your JVM is set to UTC? And if this is the time zone you want, then the result is correct. The web site seems to have picked up that you are in time zone GMT-06:00, which is not a time zone, but in any case is 6 hours behind UTC. Which accounts for the difference you are observing. Which time zone *do* you want? — Ole V.V., Dec 14 '22 at 04:01
Declare for example `private static final DateTimeFormatter DTF = DateTimeFormatter.ofPattern("u/M/d H:mm:ss");`. Then `LocalDateTime.parse(startTime, DTF).atZone(ZoneId.of("America/Winnipeg")).toInstant().toEpochMilli()` yields 315552600000, same as you see in the web site. Obviously substitute your desired time zone. java.time makes it virtually impossible to forget to specify time zone. I see that as a great advantage. — Ole V.V., Dec 14 '22 at 04:28
WARNING: A combination of an update in the tzdata database + a mistake by the OpenJDK team they are so far unwilling to rectify against the advice of the author of the java.time package means that __all date/time math on anything prior to 1970 is broken__. For most TZs, so far, no problems, but e.g. Europe/Amsterdam? Broken. You need a very new JVM (Coretto17, or the latest openjdk snapshot). Go for dates in 1943, or before 1930. — rzwitserloot, Dec 14 '22 at 05:51
That’s discomforting, @rzwitserloot. Can you link to sources and further info? — Ole V.V., Dec 14 '22 at 06:01

GreyBeardedGeek · Accepted Answer · 2022-12-14T04:44:52.447

Yes, you are missing the fact that the timezone matters. If you don't specify a timezone, your result will be for the date/time you specify in the default timezone of the computer that the code is running on.

For me, the epoch converter website gives the result "315549000000" for "1979/12/31 23:30:00", presumably because it's doing the conversion in JavaScript in the browser, and that is presumably using the timezone of my computer.

If, instead, I enter "1979/12/31 23:30:00 GMT", I get "315531000000"

So, if you want the two to match, you'll need to specify the timezone in the epoch converter, and also use the timezone in your Java/Kotlin code.

For example, if you use the date string "1979/12/31 23:30:00 America/New_York" in the epoch converter, the following code should give you the same result:

fun main(){ 
    val startTime = "1979/12/31 23:30:00 America/New_York"
    val dateFormat = DateTimeFormatter.ofPattern("yyyy/MM/dd HH:mm:ss VV")
    val parsed = ZonedDateTime.parse(startTime, dateFormat);
    println(parsed.toInstant().toEpochMilli())
}

https://www.epochconverter.com/ does not seem to understand America/New_York and just uses the time zone of my computer. Your code gives 315549000000, which is correct for New York, 5 hours behind UTC (where the OP seems to be 6 hours behind UTC). — Ole V.V., Dec 14 '22 at 06:09

Java/Kotlin String Date to milliseconds conversion

1 Answers1