Jackson Databind ObjectMapper default timezone is GMT, should be UTC

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.

Comment From: 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.

Comment From: 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 https://github.com/FasterXML/jackson-databind/issues/915#issuecomment-138726466 .

Comment From: cowtowncoder

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

Comment From: cowtowncoder

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

Comment From: cemo

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

Comment From: 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).

Comment From: 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).

Comment From: cemo

Thanks for great explanation.

Comment From: cowtowncoder

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

Comment From: francisoliverlee

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

Comment From: yawkat

OS timezone is rarely what you want, so it's better to require making that decision explicitly.

Comment From: francisoliverlee

it's not about how rarely it is but how to get timezone by default. imo, 1. timezone user set 2. timezone jvm set 3. timezone os set

now, user does not set timezone, but jackson sets UTC by default which should get from jvm

Comment From: yihtserns

☝️ https://github.com/FasterXML/jackson-databind/issues/915#issuecomment-291168664:

Comment From: cowtowncoder

We should not rely on whatever JVM or OS defaults might be. As per my earlier comments, JSON is data interchange format across systems, so settings of particular OS or JVM are generally meaningless. UTC seems like the universal default: if user wants something else, let them configure ObjectMapper.

Comment From: francisoliverlee

We should not rely on whatever JVM or OS defaults might be. As per my earlier comments, JSON is data interchange format across systems, so settings of particular OS or JVM are generally meaningless. UTC seems like the universal default: if user wants something else, let them configure ObjectMapper.

got your idea , CoC. golang uses UTF8 as default too.

but issue comes, we set java property user.timezone, and not work in ObjectMapper as expected, it breaks write onece and run everywhere. jackson is an lib in java, and should follow java-platform rules. it can use its own default value as UTC if not set user.timezone in java.