【问题标题】：Java Date forcing BST "timezone"Java日期强制BST“时区”
【发布时间】：2015-04-17 09:30:33
【问题描述】：

在 JAVA 中，如何确保所有日期都返回为 GMT 日期？

例如，即使我尝试强制使用 GMT 语言环境的 DateFormat，它也会应用某种检索 BST 日期的逻辑。

public static void main(String[] args) throws ParseException {
    DateFormat dd = new SimpleDateFormat("MMM dd HH:mm:ss zzz yyyy");
    dd.setTimeZone(TimeZone.getTimeZone("GMT"));
    Date parse = dd.parse("Out 29 23:00:00 GMT 2011");
    Date parse2 = dd.parse("Out 30 23:00:00 GMT 2011"); 
    System.out.println(parse); // Prints "Sun Oct 30 00:00:00 BST 2011"
    System.out.println(parse2); // Prints "Sun Oct 30 23:00:00 GMT 2011"
    System.out.println(Locale.getDefault()); // Prints "en_US"
    System.out.println(TimeZone.getDefault().getID());  // Prints "Europe/London"
}

BST 来自哪里？它与夏令时有关吗？ TimeZone 类则不然。

    System.out.println(TimeZone.getTimeZone("GMT").inDaylightTime(parse)); // Prints "false"
    System.out.println(TimeZone.getTimeZone("GMT").inDaylightTime(parse2)); // Prints "false"

默认系统区域设置为 en_US。

编辑：根据 Basil Bourque 的回复，如果我将默认时区更改为 GMT，我可以将两个打印件都打印到 GMT 日期：

    TimeZone.setDefault(TimeZone.getTimeZone("GMT"));

【问题讨论】：

时区适用于DateFormat，不适用于Date，后者没有时区的概念。您正在将Date 传递给println，这与您的DateFormat 没有任何关系来创建其输出。
@GriffeyDog 值得成为答案而不是评论。
记录在案...当心致电TimeZone.setDefault。适合快速测试。但在生产中存在风险，因为它会立即影响在该 JVM 中所有应用程序的所有线程中运行的所有当前和未来代码。

标签： java date

【解决方案1】：

谜题

你确定你在System.out.println 行上的cmets 都是正确的吗？我希望两条线的输出具有相同的时区，BST 或 GMT。

如果您确定这些是正确的，请发布一个完整的工作代码示例。还要记录您的默认语言环境和时区。

完整的工作示例

这是我将您的代码转换为完整工作示例的版本。我从BST 和out 推断这是葡萄牙语巴西语言环境。

java.util.Locale.setDefault( new Locale.Builder().setLanguage( "pt" ).setRegion( "BR" ).build() );  // **HACK* Think twice before ever setting the default of your JVM’s locale or time zone. Generally a bad idea.
java.text.DateFormat dd = new java.text.SimpleDateFormat( "MMM dd HH:mm:ss zzz yyyy" );
dd.setTimeZone( java.util.TimeZone.getTimeZone( "GMT" ) );
Date parse = null;
Date parse2 = null;
try {
    parse = dd.parse( "Out 29 23:00:00 GMT 2011" );
    parse2 = dd.parse( "Out 30 23:00:00 GMT 2011" );
} catch ( ParseException ex ) {
    Logger.getLogger( JodaTimeWork.class.getName() ).log( Level.SEVERE , null , ex );
}
System.out.println( parse ); 
System.out.println( parse2 );

我在US 语言环境和America/Los_Angeles 时区运行时的输出，因此是PDT 时区。

Sat Oct 29 16:00:00 PDT 2011
Sun Oct 30 16:00:00 PDT 2011

`Date` 对象上没有时区

请注意，java.util.Date 对象没有指定时区†。令人困惑的是，该类上的 toString 方法实现应用了 JVM 当前的默认时区。所以它似乎像 Date 对象有一个时区，但它没有。

正如GriffeyDog 的正确评论所说，DateFormat 对象有一个时区，但 Date 对象没有。

所以我希望你的两个System.out.println 行都发出具有相同时区的文本，正如我在上面所说的那样。

乔达时间 | java.time

这种令人困惑的时区处理是避免使用 java.util.Date/.Calendar 和 SimpleTextFormat 的众多原因之一。知情人士使用Joda-Time 库或Java 8 中内置的新java.time package。java.time 包的灵感来自Joda-Time，但经过重新设计；各有优缺点。

Joda-Time 中的示例

这是 Joda-Time 2.7 中的一个示例。

`DateTime` 上的时区

Joda-Time 中的 DateTime 对象知道自己分配的时区，这与 java.util.Date 对象不同。

不正确的本地化

您的输入数据对Out 使用大写的O 似乎不符合葡萄牙语惯例。我的示例将其更正为小写。 Joda-Time 拒绝大写为无效。

代码

String input1 = "out 29 23:00:00 GMT 2011";
String input2 = "out 30 23:00:00 GMT 2011";

Locale locale_pt_BR = new Locale.Builder().setLanguage( "pt" ).setRegion( "BR" ).build(); //
DateTimeFormatter formatter = DateTimeFormat.forPattern( "MMM dd HH:mm:ss 'GMT' yyyy" ).withLocale( locale_pt_BR ).withZone( DateTimeZone.UTC );

DateTime dateTime1 = null;
DateTime dateTime2 = null;
DateTime dateTime1_Sao_Paulo = null;
DateTime dateTime2_Sao_Paulo = null;
try {
    dateTime1 = formatter.parseDateTime( input1 );
    dateTime2 = formatter.parseDateTime( input2 );
    // Adjust to "America/Sao_Paulo" time zone.
    DateTimeZone zone_Sao_Paulo = DateTimeZone.forID( "America/Sao_Paulo" );
    dateTime1_Sao_Paulo = dateTime1.withZone( zone_Sao_Paulo );
    dateTime2_Sao_Paulo = dateTime2.withZone( zone_Sao_Paulo );
} catch ( IllegalArgumentException e ) {
    // … Handle exception.
    System.out.println( "ERROR - Unexpected input for parsing into a date-time object." );
}

转储到控制台。

System.out.println( "dateTime1 : " + dateTime1 );
System.out.println( "dateTime2 : " + dateTime2 );
System.out.println( "Adjusted to America/Sao_Paulo: " + dateTime1_Sao_Paulo + " & " + dateTime2_Sao_Paulo );

运行时。

dateTime1 : 2011-10-29T23:00:00.000Z
dateTime2 : 2011-10-30T23:00:00.000Z
Adjusted to America/Sao_Paulo: 2011-10-29T21:00:00.000-02:00 & 2011-10-30T21:00:00.000-02:00

ISO 8601

如果您对输入数据的格式有任何控制或影响，我强烈建议您更改为标准的ISO 8601 格式。

例如：2015-02-15T19:39:11Z.

时区

避免时区的 3 或 4 个字母代码。它们既不是标准化的，也不是唯一的。 BST 例如可以是：

British Summer Time（自 1971 年起已过时，但仍是 Google 热门歌曲）
Brazil Standard Time
Bangladesh Standard Time

使用proper time zone names。示例：America/Sao_Paulo。

Joda-Time 拒绝的 3-4 个字母代码

由于频繁的重复值，不可能负责任地解析这些值。所以 Joda-Time 拒绝尝试。

请注意上面的示例代码中我是如何硬编码预期的GMT 值的。请参阅“GMT”字母周围的单引号 (APOSTROPHE)。这告诉 Joda-Time 在解析时期望并忽略该字符串。

这有一个至关重要的后果：由于没有确定的时区或与 UTC 的偏移量，Joda-Time 在解析字符串时不知道如何解释日期时间。我们将格式化程序设置为一个时区，通过该时区来解释没有时区或偏移量的字符串。如果字符串 did 有偏移量，则在格式化程序上设置时区具有不同的行为：解析后，格式化程序会将值调整为该时区。

† 更令人困惑的是，java.util.Date 实际上确实有一个时区，但深埋在它的实现中。出于大多数实际目的，该时区被忽略。因此，简而言之，我们说 j.u.Date 没有时区（实际上就像在 UTC 中一样）。

【讨论】：

谜题