I have read that, and as I wrote I have a workaround. My question was regarding the inner workings of the DateTimeType, especially when parsing a string, since it obviously doesn’t handle it in the same way as Joda DateTime. My question is if there is a reason it disregards the timezone and always assume local time, or if this is an oversight in the implementation, that should be corrected.
For reference I tried replacing the “Z” with “+0200”, but with the same result, so it seems like it doesn’t take that part of the string into account, when parsing it.
Edit: I realized that setting “+0200” is supposed to produce the same value as using local time. When I instead changed it to “+0000” it set the correct time! So it would seem that it doesn’t recognize the “Z” to mean UTC, and instead interpret it as local time. Should this be reported as a bug?
Edit2: After looking at the ESH sourcecode for the DateTimeType and made some more tests i’ve come to the following hypothesis:
When parsing a datestring, four different formats are tested against.
public static final String DATE_PATTERN = "yyyy-MM-dd'T'HH:mm:ss";
public static final String DATE_PATTERN_WITH_TZ = "yyyy-MM-dd'T'HH:mm:ssz";
public static final String DATE_PATTERN_WITH_TZ_AND_MS = "yyyy-MM-dd'T'HH:mm:ss.SSSZ";
public static final String DATE_PATTERN_WITH_TZ_AND_MS_ISO = "yyyy-MM-dd'T'HH:mm:ss.SSSX";
When testing different formats:
- 2017-08-10T17:59:33+0000 - Works
- 2017-08-10T17:59:33.000Z - Works
- 2017-08-10T17:59:33Z - Doesn’t work.
1 gets matched by DATE_PATTERN_WITH_TZ
2 gets matched by DATE_PATTERN_WITH_TZ_AND_MS_ISO
3 gets matched by DATE_PATTERN, because the “Z” is only recognized by “ISO 8601 Time zone” (X in SimpleDateFormat) and therefore discarded and no timezone is applied.
The solution would be to add
public static final String DATE_PATTERN_WITH_TZ_ISO = "yyyy-MM-dd'T'HH:mm:ssX";
to the list of valid date formats in the DateTimeType class.
@Kai, am I correct?