admin管理员组

文章数量:1123367

In Android Studio (Kotlin):

val calendar = Calendar.getInstance()
calendar.set(1900, 0, 7, 0, 0, 0)
println(calendar.timeInMillis)
println(calendar.time)
// -2208484952073
// Sun Jan 07 00:00:00 YEKT 1900

In browser (Kotlin):

val calendar = Calendar.getInstance()
val timeZone = 5 * 60 * 60 * 1000
calendar.timeInMillis = -2208484952073 + timtZone
println(calendar.time)
// Sun Jan 07 00:57:27 UTC 1900

Why does it return a different time? 00:57:27 instead of 00:00:00

In Android Studio (Kotlin):

val calendar = Calendar.getInstance()
calendar.set(1900, 0, 7, 0, 0, 0)
println(calendar.timeInMillis)
println(calendar.time)
// -2208484952073
// Sun Jan 07 00:00:00 YEKT 1900

In browser (Kotlin):

val calendar = Calendar.getInstance()
val timeZone = 5 * 60 * 60 * 1000
calendar.timeInMillis = -2208484952073 + timtZone
println(calendar.time)
// Sun Jan 07 00:57:27 UTC 1900

Why does it return a different time? 00:57:27 instead of 00:00:00

Share Improve this question edited 12 hours ago Mark Rotteveel 109k225 gold badges155 silver badges218 bronze badges asked 13 hours ago Feuer und WasserFeuer und Wasser 274 bronze badges 4
  • 3 Whatever the timezone YEKT is, it isn't UTC, and especially time zones in the past can have very wonky offsets, so assuming that the current timezone offset was also the correct and valid offset in 1900 is a pretty big assumption on your part. Which is why you 1) shouldn't do such calculations yourself, but use the timezone information Java/Kotlin has and 2) you really shouldn't use outdated classes like Calendar, but instead use the java.time classes like ZonedDateTime. – Mark Rotteveel Commented 12 hours ago
  • Specifically, in 1900 (until 1916-07-02), Asia/Yekaterinburg had an offset of 242 minutes (and some seconds, but I'm using a source that only provides minutes offset). – Mark Rotteveel Commented 12 hours ago
  • 1 @Computable While most of the weirder offsets are "pre-epoch", it is entirely unrelated to the epoch. It is simply, in the past, as in "a long time ago"; I guess most of the weirdness disappeared around WW2, but I'm not sure if that is related, or just that time and coordination between countries and thus time zones became more important with the economic and communication changes in the early 20th century, so having offsets in whole hours (or at least half hours) made things simpler. – Mark Rotteveel Commented 12 hours ago
  • fyi ZonedDateTime.of(1900, Month.JANUARY.getValue(), 7, 0, 0, 0, 0, ZoneId.of("Asia/Yekaterinburg")).getOffset(); produces +04:02:33 and ZonedDateTime.of(1900, Month.JANUARY.getValue(), 7, 0, 0, 0, 0, ZoneId.of("Asia/Yekaterinburg")).toInstant().toEpochMilli(); produces -2208484953000 – g00se Commented 12 hours ago
Add a comment  | 

1 Answer 1

Reset to default 4

The difference is that a hundred years Yekaterinburg Time (YEKT) was different, according to this site in 1900 it was UTC +4:02:33.

UPD:

There's definitely a +4:02:33 difference there (Kotlin playground):

import java.util.*

fun main() {
    printTime("UTC")
    printTime("Asia/Yekaterinburg")
}

fun printTime(timeZone: String) {
    val calendar = Calendar.getInstance(TimeZone.getTimeZone(timeZone))
    calendar.set(1900, 0, 7, 0, 0, 0)
    println(calendar.timeInMillis)
    println(calendar.time)
}

Results:

Sun Jan 07 00:00:00 UTC 1900
Sat Jan 06 19:57:27 UTC 1900

本文标签: Kotlin Calendar returns different values in Android studio and kotlin onlineStack Overflow