在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"));
答案 0 :(得分:1)
您确定您对System.out.println
行的评论是否正确?我希望两个行的输出具有相同的时区,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.util.Date/.Calendar& amp; SimpleTextFormat。知道的人使用Joda-Time库或Java 8中内置的新java.time package .java.time包的灵感来自Joda-Time,但是重新设计了;每个都有自己的优点和缺点。
这是Joda-Time 2.7中的一个例子。
DateTime
与java.util.Date对象不同,Joda-Time中的DateTime
对象知道自己指定的时区。
您的输入数据对O
使用大写Out
似乎对于葡萄牙语惯例不正确。我的例子将其修正为小写。 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格式。
示例: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拒绝尝试。
请注意上面的示例代码中我如何硬编码预期的GMT
值。查看" GMT"周围的单引号(APOSTROPHE)。字母。这告诉Joda-Time在解析时期望并忽略该字符串。
这有一个至关重要的结果:没有确定的时区或从UTC偏移,Joda-Time在解析字符串时不知道如何解释日期时间。我们将格式化程序设置为一个时区,通过该时区解释没有时区或偏移量的字符串。如果字符串 具有偏移量,则在格式化程序上设置时区具有不同的行为:在解析后,格式化程序会将值调整为该时区。
†更令人困惑的是,java.util.Date实际上确实有一个时区,但深埋在其实现中。出于大多数实际目的,该时区被忽略。因此,作为简写,我们说j.u.Date没有时区(实际上就像在UTC中一样)。