Vis*_*l A 0 java timestamp java.util.date
我正在尝试将 转换IST为UTC纪元Java
但不是从 中减去 5.30 小时IST，而是在 中添加 5.30IST
public static long convertDateToEpochFormat(String date) {
Date convertedDate = null;
try {
LOGGER.info(date);
DateFormat formatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
formatter.setTimeZone(TimeZone.getTimeZone("UTC"));
LOGGER.info(date);
convertedDate = formatter.parse(date);
LOGGER.info(convertedDate);
} catch (ParseException e) {
e.printStackTrace();
}
return convertedDate.getTime() / 1000L;
}
我获得的日志语句是：
2017-01-01 00:00:00
2017-01-01 00:00:00
Sun Jan 01 05:30:00 IST 2017
由于 UTC 转换，理想情况下应为 12 月 31 日 18:30:00。
谁能告诉我怎么了？
\n\n\nWhy does util.Date forwards the date instead of subtracting it?
\n
Because India time is ahead of UTC, not behind.
\n\nInstant.parse(\n "2017-01-01 00:00:00".replace( " " , "T" ) + "Z" \n).atZone(\n ZoneId.of( "Asia/Kolkata" )\n).toString()\n\n\n\n2017-01-01T05:30+05:30[Asia/Kolkata]
\n
You are using troublesome old date-time classes that are now legacy, supplanted by the java.time classes.
\n\nYour input string is almost in standard ISO 8601 format. To comply fully, replace that SPACE in the middle with a T. The java.time classes use standard formats when parsing/generating strings. So no need to specify a formatting pattern.
String input = "2017-01-01 00:00:00".replace( " " , "T" ) ;\nIf that input is meant to represent a moment in UTC, append a Z, short for Zulu, means UTC.
String input = "2017-01-01 00:00:00".replace( " " , "T" ) + "Z" ; // Assuming this input was intended to be in UTC.\n\n\n\n2017-01-01T00:00:00Z
\n
When possible, just use the ISO 8601 formats in the first place when serializing date-time values to strings.
\n\nInstantParse that input string as an Instant, a moment on the timeline in UTC with a resolution of nanoseconds.
Instant instant = Instant.parse( input ) ;\n\n\n\ninstant.toString(): 2017-01-01T00:00:00Z
\n
ZonedDateTimeYou seem to want this value adjusted into India time. Apply a ZoneId to get a ZonedDateTime.
Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 3-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "Asia/Kolkata" ) ;\nZonedDateTime zdt = instant.atZone( z ) ;\n\n\n\nzdt.toString(): 2017-01-01T05:30+05:30[Asia/Kolkata]
\n
See this code run live at IdeOne.com.
\n\nYour Question expects the India time to go backwards, behind the UTC value. This makes no sense. India time is ahead of UTC, not behind UTC. The Americas have time zones behind UTC as they lay westward. East of the Prime Meridian in Greenwich are offsets ahead of UTC. In modern times, ISO 8601 and most other protocols mark such offsets with a plus sign: +05:30. Note that some old protocols did the opposite (used a negative sign).
因此，UTC 午夜（本初子午线 00:00:00）同时也是印度的凌晨 5 点 30 分。
\n\n所以这三个都代表同一个同时发生的时刻, the same point in the timeline:
\n\n2017-01-01T00:00:00Z2017-01-01T05:30+05:30[Asia/Kolkata]2016-12-31T16:00-08:00[America/Los_Angeles]不要将时间作为从纪元开始的整数计数来处理，就像您通过long从方法中返回 a 所做的那样，如问题中所示。在 Java 代码中，使用日期时间对象（特别是 java.time 对象）传递日期时间值。在 Java 代码外部传递日期时间值时，请使用实用的ISO 8601序列化为字符串 formats.
依赖于从纪元开始计数的整数值是令人困惑的，难以调试，无法被人类阅读，并且会导致挫败感和错误（更糟糕的是：未被观察到的） errors).
\n\njava.time框架内置于 Java 8 及更高版本中。这些类取代了麻烦的旧遗留日期时间类，例如java.util.Date, Calendar, &SimpleDateFormat.
Joda -Time项目目前处于维护模式，建议迁移到java.time classes.
\n\n要了解更多信息，请参阅Oracle 教程。并在 Stack Overflow 上搜索许多示例和解释。规格为JSR 310.
\n\n从哪里获取 java.time 类？
\n\nThreeTen -Extra项目通过附加类扩展了 java.time。该项目是 java.time 未来可能添加的内容的试验场。您可能会在这里找到一些有用的类，例如Interval、、等YearWeekYearQuarter。