ObjectMapper default timezone is GMT, should be UTC

[obozek]

ObjectMapper is configured with GMT timezone:

protected final static BaseSettings DEFAULT_BASE = new BaseSettings(
            null, // can not share global ClassIntrospector any more (2.5+)
            DEFAULT_ANNOTATION_INTROSPECTOR,
            STD_VISIBILITY_CHECKER, null, TypeFactory.defaultInstance(),
            null, StdDateFormat.instance, null,
            Locale.getDefault(),
//            TimeZone.getDefault()
            TimeZone.getTimeZone("GMT"),  // <= HERE
            Base64Variants.getDefaultVariant() // 2.1
    );

(it's on line 280)

But on many places in documentation and even in javadoc it's written that it's configured with UTC timezone. It is even cleaner to use UTC.

[cowtowncoder]

Yes, the use of GMT is an old oversight, from the time when I did not realize that the two are not the same. The main concern at this point is simply whether change could cause backwards compatibility issues. For 2.6 I did try out to see how many unit tests would fail; the number was low (I think 2), and none seemed necessarily valid failure.

But this is probably something that should still be discussed on jackson-dev list, since there are possibly significant backwards compatibility risks.

[obozek]

Anyway it should definitely be synchronized with javadoc/documentation. I
noticed this problem only when timezone names were serilaside to json and
my tests failed.
Dne 9. 9. 2015 1:00 napsal uživatel "Tatu Saloranta" <
notifications@github.com>:

Yes, the use of GMT is an old oversight, from the time when I did not
realize that the two are not the same. The main concern at this point is
simply whether change could cause backwards compatibility issues. For 2.6 I
did try out to see how many unit tests would fail; the number was low (I
think 2), and none seemed necessarily valid failure.

But this is probably something that should still be discussed on
jackson-dev list, since there are possibly significant backwards
compatibility risks.

—
Reply to this email directly or view it on GitHub
#915 (comment)
.

[cowtowncoder]

Agreed. I would prefer move to UTC, as documented, but just wanted to point out the challenge.

[cowtowncoder]

Changed for 2.7.0 so that default TimeZone for core jackson-databind is now UTC, consistently.
No apparent breakage wrt unit tests.

[cemo]

@cowtowncoder why not using java's default time zone?

[cowtowncoder]

@cemo partly because use of local timezone is mostly an anti-pattern (that is, developers use it without realizing, causing issues). And this because similar to "default encoding" it is often somewhat arbitrary what the timezone might be. I guess this is just one argument in two parts...
But basically use of local timezones seemed to me to be a source of many kinds of preventable problems.

So, to me it is similar to "why default to UTF-8 instead of platform default encoding", although it is not exactly the same thing (because JSON mandates UTF-8 as default etc).

[cowtowncoder]

Oh. And probably the bigger reason: since json is typically shared between two systems (sender/receiver) and those often have different default timezones, reliance on shared setting seems especially brittle. While timezone in use should be included in date/time values, and thereby setting should only affect serialization, it also seems likely that there are cases that would implicitly rely on shared setting, which could lead to nasty surprises (works during tests, fails in production).

[cemo]

Thanks for great explanation.

[cowtowncoder]

@cemo thank you for asking a good question: sometimes there are no good reasons, or reasons seem less convincing than what I thought.

[francisoliverlee]

why not follow timezone set by jvm , os?
@cowtowncoder