Java XStream -Serializing Date объекты приводят к неправильному времени на час

Question

Я использую XStream для сериализации объекта, который содержит поле Date, в XML и обратно. Однако даты, записанные в XML, на час раньше, чем действительные даты, которые я создал.

MyComplexObject o = new MyComplexObject();
o.addChild(new MyComplexObjectChild(2, {0.1, 0.1, 0.2, 0.3, 0.5}, new Date(1111111111));
System.out.println(new Date(1111111111)); //Tue Jan 13 21:38:31 GMT 1970
//serialize using XStream

Это выводимый XML:

 <MyComplexObject>           
     <children>
         <MyComplexObjectChild>
              <someNumber>2</someNumber>
              <someOtherNumbers>
                  <double>0.1</double>
                  <double>0.1</double>
                  <double>0.2</double>
                  <double>0.3</double>
                  <double>0.5</double>
              </someOtherNumbers>
              <date>1970-01-13 21:38:31.111 GMT</date>
        </MyComplexObjectChild>
    </children>
</MyComplexObject>

Теперь десериализовать с помощью XStream:

MyComplexObject o = xstream.fromXML(output);
System.out.println(o.getDate()) //Tue Jan 13 22:38:31 GMT 1970

Как вы видите, выходная дата составляет час - как я могу это исправить?

Приветствия

Пит

Answer 1

Я подозреваю, что в вашей JRE происходит что-то странное:

import java.util.*;

public class Test {
  public static void main(String[] args) {
      Date d = new Date(1111111111);
      System.out.println(d); // Prints Tue Jan 13 21:38:31 GMT 1970
  }
}

Так что XML выглядит корректно для меня.

Тестирование с C # просто для проверки ...

РЕДАКТИРОВАТЬ: Просто чтобы еще больше запутать вещи, .NET и Mono, кажется, думают, что это 20: 38: 31: использование системы;

class Test
{
    static void Main()
    {
        DateTimeOffset epoch = new DateTimeOffset(1970, 1, 1, 0, 0, 0,
                                                  TimeSpan.Zero);
        TimeSpan millis = TimeSpan.FromMilliseconds(1111111111);
        // Prints 1970-01-13 20:38:31Z
        Console.WriteLine((epoch + millis).ToString("u"));
    }
}

Я в замешательстве ...

РЕДАКТИРОВАТЬ: Хорошо, мы можем решить это довольно легко.1111111111 миллисекунд составляют ~ 308,64 часа, то есть 12 дней и 20 часов ... что означает, что .NET здесь.

У меня нет понятия почему Java заявляет, что это 9 вечера.Попытка с Joda ...

РЕДАКТИРОВАТЬ: Joda подтверждает результат .NET:

import org.joda.time.*;

public class Test {
  public static void main(String[] args) {
      DateTime dt = new DateTime(1111111111, DateTimeZone.UTC);
      System.out.println(dt); // Prints 1970-01-13T20:38:31.111Z
  }
}

Таким образом, остается два вопроса:

• Почему машина OPпечать 22: 38: 31?
• Почему мой аппарат печатает 21: 38: 31?

РЕДАКТИРОВАТЬ: Хорошо, прогресс:

import java.util.*;
import java.text.*;

public class Test {
  public static void main(String[] args) {
      Date date = new Date(1111111111);
      DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss z");
      df.setTimeZone(TimeZone.getTimeZone("UTC"));
      // Prints 1970-01-13 20:38:31 UTC
      System.out.println(df.format(date));
  }
}

I интересно , не было ли GMT в UTC в 1970 году, что объясняло бы вещи ... проверяя сейчас ...

РЕДАКТИРОВАТЬ: Хорошо, у меня есть некоторое представление о том, что вызывает здесь путаницу.С 27 октября 1968 года по 31 октября 1971 года Великобритания была в UTC + 1 (фактически - сам UTC не был введен до 1972 года).Поэтому, когда здесь говорится «GMT», это на самом деле означает «часовой пояс Европы / Лондона в это время», который на самом деле не был GMT.Особенно прискорбно, что эта странность произошла в эпоху Unix ...