XStream
  1. XStream
  2. XSTR-768

ISO8601GregorianCalendarConverter invalid conversion between time zones

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.4.7
    • Fix Version/s: 1.4.8
    • Component/s: Converters
    • Labels:
      None
    • JDK version and platform:
      Oracle 1.7 for Windows

      Description

      We have recently been experiencing issues deserialising XML with specific time zones. This only seems to be occurring on Windows where the time zone does not have an Id that is in the available list of Ids. It seems this is caused by Windows not using the Olson time zone database.

      For example, when setting the system time zone to GMT-12:00 and calling TimeZone.getDefault().getID() the JRE will return "GMT-12:00". Joda time knows about this and if you try and use this to convert to a Joda DateTimeZone it will strip of the "GMT" prefix and return a time zone with Id of "-12:00".

      The problem seems to be in com.thoughtworks.xstream.converters.extended.ISO8601GregorianCalendarConverter.fromString(String). This has the following code:

      ...
      String timeZoneID = TimeZone.getDefault().getID();
      for (int i = 0; i < formattersNoUTC.length; i++ ) {
      	try {
      		DateTimeFormatter formatter = formattersNoUTC[i].withZone(DateTimeZone.forID(timeZoneID));
      		...
      	} ...
      }
      ...
      

      This code is getting the time zone Id from the JRE and then passing this to DateTimeZone.forID to convert to a Joda time zone. This doesn't work when the time zone Id is not in the available list of Ids. There is an invalid assumption that the same time zone Id from the JRE can be used to get the Joda time zone.

      There is actually no need to even use the Id here, the code could simply be:

      ...
      final DateTimeZone dtz = DateTimeZone.getDefault();
      for (int i = 0; i < formattersNoUTC.length; i++ ) {
      	try {
      		DateTimeFormatter formatter = formattersNoUTC[i].withZone(dtz);
      		...
      	} ...
      }
      ...
      

      This ignores the problem entirely and uses the time zone reported by Joda directly.

        Activity

        Jason Steenstra-Pickens made changes -
        Field Original Value New Value
        Description We have recently been experiencing issues deserialising XML with specific time zones. This only seems to be occurring on Windows where the time zone does not have an Id that is in the available list of Ids. It seems this is caused by Windows not using the Olson time zone database.

        For example, when setting the system time zone to GMT-12:00 and calling {{TimeZone.getDefault().getID()}} the JRE will return "GMT-12:00". Joda time knows about this and if you try and use this to convert to a Joda DateTimeZone it will strip of the "GMT" prefix and return a time zone with Id of "-12:00".

        The problem seems to be in {{com.thoughtworks.xstream.converters.extended.ISO8601GregorianCalendarConverter.fromString(String)}}​. This has the following code:
        {code}
        ...
        String timeZoneID = TimeZone.getDefault().getID();
        for (int i = 0; i < formattersNoUTC.length; i++ ) {
        try {
        DateTimeFormatter formatter = formattersNoUTC[i].withZone(DateTimeZone.forID(timeZoneID));
        ...
        } ...
        }
        ...
        {code}

        This code is getting the time zone Id from the JRE and then passing this to {{DateTimeZone.forID}} to convert to a Joda time zone. This doesn't work when the time zone Id is not in the available list of Ids. There is an invalid assumption that the same time zone Id from the JRE can be used to get the Joda time zone.

        There is actually no need to even use the Id here, the code could simply be:
        {code}
        ...
        final DateTimeZone dtz = DateTimeZone.getDefault();
        for (int i = 0; i < formattersNoUTC.length; i++ ) {
        try {
        DateTimeFormatter formatter = formattersNoUTC[i].withZone(dtz);
        ...
        } ...
        }
        ...
        {code}

        This ignores the problem entirely and uses the time zone reported by Joda directly.
        We have recently been experiencing issues deserialising XML with specific time zones. This only seems to be occurring on Windows where the time zone does not have an Id that is in the available list of Ids. It seems this is caused by Windows not using the Olson time zone database.

        For example, when setting the system time zone to GMT-12:00 and calling {{TimeZone.getDefault().getID()}} the JRE will return "GMT-12:00". Joda time knows about this and if you try and use this to convert to a Joda DateTimeZone it will strip of the "GMT" prefix and return a time zone with Id of "-12:00".

        The problem seems to be in {{com.thoughtworks.xstream.converters.extended.ISO8601GregorianCalendarConverter.fromString(String)}}. This has the following code:
        {code}
        ...
        String timeZoneID = TimeZone.getDefault().getID();
        for (int i = 0; i < formattersNoUTC.length; i++ ) {
        try {
        DateTimeFormatter formatter = formattersNoUTC[i].withZone(DateTimeZone.forID(timeZoneID));
        ...
        } ...
        }
        ...
        {code}

        This code is getting the time zone Id from the JRE and then passing this to {{DateTimeZone.forID}} to convert to a Joda time zone. This doesn't work when the time zone Id is not in the available list of Ids. There is an invalid assumption that the same time zone Id from the JRE can be used to get the Joda time zone.

        There is actually no need to even use the Id here, the code could simply be:
        {code}
        ...
        final DateTimeZone dtz = DateTimeZone.getDefault();
        for (int i = 0; i < formattersNoUTC.length; i++ ) {
        try {
        DateTimeFormatter formatter = formattersNoUTC[i].withZone(dtz);
        ...
        } ...
        }
        ...
        {code}

        This ignores the problem entirely and uses the time zone reported by Joda directly.
        Hide
        Jörg Schaible added a comment -

        Well, as soon I apply your proposed change, we have a failing unit test. Problem is, that DateTimeZone.getDefault() does not (and cannot) take into account if a user changed the default of the Java runtime using TimeZone.setDefault("CEST").

        However, we have an additional problem since Java 6, because since this runtime version we have localized time zone abbreviations. E.g. with a German default locale we get MESZ (Mittel-Europäische SommerZeit) instead of CEST (Central European Summer Time). What a mess!

        Show
        Jörg Schaible added a comment - Well, as soon I apply your proposed change, we have a failing unit test. Problem is, that DateTimeZone.getDefault() does not (and cannot) take into account if a user changed the default of the Java runtime using TimeZone.setDefault("CEST"). However, we have an additional problem since Java 6, because since this runtime version we have localized time zone abbreviations. E.g. with a German default locale we get MESZ (Mittel-Europäische SommerZeit) instead of CEST (Central European Summer Time). What a mess!
        Hide
        Jörg Schaible added a comment -

        Does this work for you?

        final DateTimeZone dtz = DateTimeZone.forTimeZone(TimeZone.getDefault());
        
        Show
        Jörg Schaible added a comment - Does this work for you? final DateTimeZone dtz = DateTimeZone.forTimeZone(TimeZone.getDefault());
        Hide
        Jason Steenstra-Pickens added a comment -

        Yeah that looks like it should work. That is what the static constructor of Joda DateTimeZone does to set the default anyway.

        Show
        Jason Steenstra-Pickens added a comment - Yeah that looks like it should work. That is what the static constructor of Joda DateTimeZone does to set the default anyway.
        Jörg Schaible made changes -
        Resolution Fixed [ 1 ]
        Fix Version/s 1.4.x Maintenance [ 19602 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Jörg Schaible made changes -
        Fix Version/s 1.4.x Maintenance [ 19602 ]
        Fix Version/s 1.4.8 [ 20992 ]
        Jörg Schaible made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Jörg Schaible
            Reporter:
            Jason Steenstra-Pickens
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: