嘿，这个问题我之前也碰到过类似的，咱们来一步步捋清楚原因和解决办法：

核心问题：时间戳的时区含义搞混了 #

你写的两行代码本质上拿到的是同一个时间戳的不同形式，但显示逻辑的差异导致了结果偏差：

• Calendar.getInstance().time得到的Date对象本身只是一个UTC时间戳的容器（存储从1970-01-01 00:00:00 UTC到现在的毫秒数），它本身不带时区信息。当你直接显示这个Date时，系统会自动用你手机的本地时区去解析它，所以你看到的是正确的本地时间。
• 而Calendar.getInstance().time.time / 1000直接提取了这个UTC毫秒数转成的秒数。如果你之后把这个秒数转成可读时间时，没有考虑本地时区的偏移（比如直接把它当成本地时间的秒数来解析，或者用UTC时区显示），就会出现比实际本地时间早1小时的情况——比如你的时区是UTC+1，UTC时间本身就比本地时间晚1小时，误把UTC秒数当成本地时间秒数，自然就会显示早1小时。

两种修正思路，看你的需求 #

1. 如果你需要本地时间对应的秒数

也就是从本地时区的1970-01-01 00:00:00到现在的秒数，需要加上时区偏移：

val calendar = Calendar.getInstance()
// 获取本地时区与UTC的偏移毫秒数
val zoneOffset = calendar.timeZone.rawOffset
// 计算本地时间对应的秒数
val localTimeSeconds = (calendar.timeInMillis + zoneOffset) / 1000

更推荐用Java 8+的时间API（Android API 26+可用，低版本可以用ThreeTenABP库兼容），它的时区处理更清晰直观：

import java.time.LocalDateTime
import java.time.ZoneOffset

val localTimeSeconds = LocalDateTime.now()
    .toEpochSecond(ZoneOffset.systemDefault().rules.getOffset(java.time.Instant.now()))

2. 如果你需要的是UTC秒数，只是显示要转成本地时间

那确保在解析秒数为可读时间时，明确使用本地时区：

import java.text.SimpleDateFormat
import java.util.*

val utcSeconds = Calendar.getInstance().time.time / 1000
val sdf = SimpleDateFormat("yyyy-MM-dd HH:mm:ss", Locale.getDefault())
// 明确设置为本地时区
sdf.timeZone = TimeZone.getDefault()
// 把UTC秒数转成本地时间字符串
val localTimeStr = sdf.format(Date(utcSeconds * 1000))

额外排查点 #

也可以检查下手机的系统时区设置是否正确，有没有不小心切换到UTC时区？不过从你说直接用.time显示正确来看，这个概率不大，但也可以快速排除下。

备注：内容来源于stack exchange，提问作者Mohammad Kazemian