我正在使用dd-MM-yyyy
格式解析日期并在几秒钟内返回(除以1000)。当我将其转换为Unix时间戳时会出现问题,因为它会将此秒数转换为前一天。我将用我的代码和一个例子来解释:
private fun String.toTimestamp(): String {
val dateFormat = SimpleDateFormat("dd-MM-yyyy", Locale.getDefault())
return (dateFormat.parse(this).time / 1000).toString
}
如果日期是01/02/2019
(2019年2月2日),则此方法返回1548975600
。如果你将它转换为日期(我正在使用this页面),它将返回01/31/2019 @ 11:00pm (UTC)
。我尝试添加小时,分钟和秒,甚至添加时区,但它总是在前一天返回。
另一个例子:13-02-2019
> 1550012400
> 02/12/2019 @ 11:00pm (UTC)
日期来自DatePicker
,但是如果我以下一种方式创建它,它将返回正确的日期:
(Date().time / 1000).toString()
我用西班牙语和英语尝试了系统的语言,并将Locale
改为Locale.ENGLISH
和Locale("es", "ES")
,结果是一样的。
有什么建议?
在Java语法中:
private static final DateTimeFormatter dateFormatter
= DateTimeFormatter.ofPattern("dd-MM-uuuu");
public static final String toTimestamp(String dateString) {
long epochSecond = LocalDate.parse(dateString, dateFormatter)
.atStartOfDay(ZoneOffset.UTC)
.toEpochSecond();
return String.valueOf(epochSecond);
}
我们来试试吧:
System.out.println(toTimestamp("13-02-2019"));
1550016000
在链接到的Epoch Unix时间戳转换器上检查此值:
02/13/2019 @ 12:00 am(UTC)
SimpleDateFormat
是出了名的麻烦,而Date
已经过时了。相反,我使用java.time,即现代Java日期和时间API。这迫使我们明确地给出时区或偏移。在这种情况下作为预定义的常量ZoneOffset.UTC
。这反过来确保我们得到正确的结果,从而解决您的问题。另一个小优点是它给了我们从纪元以来几秒钟,所以我们不需要1000个有趣的师。
我使用的进口是:
import org.threeten.bp.LocalDate;
import org.threeten.bp.ZoneOffset;
import org.threeten.bp.format.DateTimeFormatter;
是的,java.time适用于较旧和较新的Android设备。它至少需要Java 6。
java.time
包导入(不是org.threeten.bp
)。org.threeten.bp
导入子包的日期和时间类。java.time
首次被描述。java.time
的后端到Java 6和7(JST-310的ThreeTen)。//convert seconds to date try below function
public static String convertSecondsToDate(Long date) {
try {
long dateInMiliseconds = date *1000;
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(dateInMiliseconds);
SimpleDateFormat simpleDateFormat = new SimpleDateFormat("dd-MM-yyyy");
return simpleDateFormat.format(calendar.getTime());
} catch (Exception e) {
return "";
}
}