Why does Java read its default settings from the system

Question

Java is reading the locale, timezone and encoding information (and perhaps more) from the system it is installed on.

This often brings bad surprises (brought me one just yesterday). Say your development and production servers are set to have TimeZone GMT+2. Then you deploy on a production server set to GMT. a 2-hour shift may not be easy to observe immediately. And although you can pass a TimeZone to your calendars, APIs might be instantiating calendars (or dates) using the default timezone.

Now, I know one should be careful with these settings, but are easy to miss, hence make programs more error-prone.

So, why doesn't Java have its own defaults - UTF-8, GMT, en_US (yes, I'm on non-en_US locale, but having it as default is fine). Applications could read the system settings via some API, if needed.

Thus programs would be more predictable.

So, what is the reason behind this decision?

Answer 1

This isn't unique to Java. Many systems default to the system time zone. After all, what else can they do?

Time zones are a thorny issues, particularly when the application needs to deal with several time zones. That's why sites such as this one put everything in UTC.

As for your situation, it's hard to comment because the description is rather vague but it sounds like this is your error. If you save a date (without time zone) in one place at GMT+2 and then load it another at GMT then you've done something wrong.

Answer 2

I don't see why having an extra set of defaults would make this easier. Surely those defaults would still have to be read from somewhere - so they'd presumably default from the operating system.

If you want to influence the defaults, there are usually system properties you can set when you launch your app, e.g.

java -Duser.timezone=Europe/London

etc.

Personally I think the problem isn't with the choice of default - it's the fact that it's used so easily. Even Joda Time (which I love in many, many respects) makes it too easy to accidentally use the default time zone. The same is true with encodings etc.

EDIT: Another option is to use a main method (or other early-initialization module) which calls

TimeZone.setDefault(TimeZone.getTimeZone("Etc/UTC"));

and likewise for other system-specific defaults.