我在美国的Ubuntu服务器中运行一个Java应用程序，并配置了CEST时区。

如果我在终端中运行Date命令，它将以CEST Zone时间返回日期-这是完美的。

但是在Java中，如果我运行以下代码

System.out.println (new Date ());

它给了我EDT时间。 我缺少什么配置。

参见stackoverflow.com/questions/3010035/

从控制台中获取的显示中解释日期对象时必须小心，因为它们是使用运行该程序的VM的默认TimeZone格式化的(默认情况下是从OS的时区继承的)。

当然，您可以根据Jesper的回答提供您自己的TimeZone。但是在这样做的同时，我强烈建议您使用IANA时区标识符(例如America / New_York)而不是EST。之所以如此，是因为具有"标准"的缩写未考虑日光节约。

因此，如果仅在控制台上打印日期对象，而没有得到预期的结果，则很有可能将服务器时区设置为错误的值，或者将OS设置为错误的时区。

要更改JVM时区，可以在启动时使用此参数

-Duser.timezone="America/New_York"

tl; dr

世界标准时间：

Instant.now()    // Instantiate an object capturing the current moment in UTC.

.toString()  // Generate a String representing textually that date-time value using standard ISO 8601 format.

2018-03-16T00:57:34.233762Z

分区：

ZonedDateTime.now( ZoneId.of("Africa/Tunis" ) )  // Instantiate an object representing the current moment with a wall-clock time seed by people in a particular region (time zone).

.toString()                                   // Generate a String representing textually that date-time value using standard ISO 8601 format wisely extended to append the name of the time zone in square brackets.

2018-03-16T01:57:34.233762+01:00[Africa/Tunis]

细节

Shailendra的答案是正确的。

另外，在Question中看到的Date类是麻烦的旧日期时间类的一部分，这些类现在已被遗留，完全被java.time类所取代。

java.util.Date的替换为java.time.Instant。 Instant类表示UTC时间轴上的时刻，其分辨率为纳秒(最多十进制的九(9)位数字)。

Instant::toString？始终使用UTC

调用旧类的Date::toString方法时，其作者选择的不幸行为是动态应用JVM的当前默认时区。这不会造成混乱。幸运的是，现代类无需添加任何时区即可说出简单的事实：Instant始终位于UTC中。

Instant.now().toString()

2018-03-16T00:57:34.233762Z

该字符串格式是标准的ISO 8601格式。最后的Z是Zulu的缩写，表示UTC。

CEST Zone time

没有名为CEST的时区。这样的3-4个字母名称是伪区域。它们不是标准化的。它们不是唯一的(！)。而是使用continent/region格式的正确时区。

ZoneId z = ZoneId.of("Europe/Paris" ) ;

您可以通过将ZoneId应用于Instant以获得ZoneDateTime，从UTC调整到这样的时区。

Instant instant = Instant.now() ;

ZonedDateTime zdt = instant.atZone( z ) ;

zdt.toString(): 2018-03-16T01:57:34.233762+01:00[Europe/Paris]

或使用快捷方式ZonedDateTime.now。

ZonedDateTime zdt = ZonedDateTime.now( z ) ;

您也可以将ZonedDateTime调整为另一个时区。注意，java.time使用不可变对象。因此，在调整过程中，我们会基于原始对象得到一个新的独特对象，但又不会干扰原始对象。

ZoneId zNewYork = ZoneId.of("America/New_York" ) ;

ZonedDateTime zdtNewYork = zdt.withZoneSameInstant( zNewYork ) ;

zdtNewYork.toString(): 2018-03-15T20:57:34.233762-04:00[America/New_York]

非常清楚，Instant，zdt和zdtNewYork是三个单独的对象，它们代表时间轴上的同一时刻，同一点。相同的时刻，不同的时钟时间。

I have a Java Application running in my Ubuntu Server in USA and configure CEST Time Zone

仅供参考，一般来说，服务器默认时区的最佳做法是UTC。

更重要的是，服务器操作系统和JVM的当前默认时区应与Java应用程序无关。

不要隐式依赖JVM的当前默认时区，而应始终明确指定所需/期望的时区。如上面的代码所示，将可选的ZoneId参数传递给各种java.time方法。

(顺便说一下，Locale的同上-始终指定所需/预期的语言环境，而不是隐式依赖于当前默认值。)

关于java.time

java.time框架内置于Java 8及更高版本中。这些类取代了麻烦的旧版旧式日期时间类，例如java.util.Date，Calendar和SimpleDateFormat。

现在处于维护模式的Joda-Time项目建议迁移到java.time类。

要了解更多信息，请参见Oracle教程。并在Stack Overflow中搜索许多示例和说明。规格为JSR 310。

您可以直接与数据库交换java.time对象。使用与JDBC 4.2或更高版本兼容的JDBC驱动程序。不需要字符串，不需要java.sql.*类。

在哪里获取java.time类？

Java SE 8，Java SE 9和更高版本

内置的

标准Java API的一部分，具有捆绑的实现。

Java 9添加了一些次要功能和修复。

Java SE 6和Java SE 7

java.time的许多功能在ThreeTen-Backport中都被反向移植到Java 6和7。

安卓系统

更高版本的Android捆绑了java.time类的实现。

对于早期的Android(<26)，ThreeTenABP项目改编了ThreeTen-Backport(如上所述)。请参阅如何使用ThreeTenABP…。

ThreeTen-Extra项目使用其他类扩展了java.time。该项目为将来可能在java.time中添加内容提供了一个试验场。您可能会在这里找到一些有用的类，例如Interval，YearWeek，YearQuarter等。

您说服务器配置为位于CEST时区，但是根据Java，默认时区为EDT。 Java从操作系统获取默认时区，因此您的服务器可能未正确设置为CEST。

如果要在特定时区中打印日期，请使用DateFormat并在其上设置时区：

DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss Z");

df.setTimeZone(TimeZone.getTimeZone("CET"));

System.out.println(df.format(new Date()));

注意：根据我的Java(Java 7u45)，CEST不是有效的时区。您是说"英语四级考试"吗？ (CEST是CET的夏季变体，但是如果您使用CET，则Java将在适当的时候自动在夏季显示时间)。