为什么Java从系统中读取其默认设置

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, eg

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.

Answer 3

I reckon it's because it is less surprising for more people.

Most programs (including those in other languages) use the timezone of the local deployment. That's been the case for ages. If you want something else, you can override it. Imagine if it was the other way: we'd have the same question in the reverse direction but asked by more people.

(Use UTC for timestamps where you can't just have offset-from-epoch.)

Answer 4

I can imagine this need whenever you develop an enterprise (web) application running on a server which is to be accessed by everyone at the world, but this is not needed for normal desktop applications. Try to think in their context as well. You don't want to have programming-unaware client application users to configure their default system settings only because Java has its own defaults. You as an enterprise (web) application developer truly has to take those things into account yourself.

Answer 5

If you deploy things on a production server set to GMT, the sensible default behavior is to use GMT as the default. Java is supposed to be a programming language and framework, not a whole operating-system-within-a-system.. Maintaining its own set of default settings is not part of a standard library's job.

And consider the alternate situation: if Java did maintain its own settings for things like time zones, everyone who wanted to use different settings (eg everyone not in GMT, probably ~90% of computer users) who wanted to use a Java program would have to manually change Java's time zone. It would be even more complicated for people who use systems which combine Java with some other language, because you'd have different programs on the same computer using different (and probably incompatible) settings.

Answer 6

tl;dr

“Why” is irrelevant, as frameworks and APIs providing such defaults is all-to-common.

Always pass a ZoneId & Locale explicitly, even if optional.

LocalDate.now( ZoneId.of( "Africa/Tunis" ) )

…and…

DateTimeFormatter.ofLocalizedDateTime( FormatStyle.FULL )
    .withLocale( Locale.JAPAN )

Specify optional arguments

Not only is the JVM's current default time zone and locale outside your control as a programmer (coming from host OS or from JVM launch parameters), they can change at any moment during runtime. Any code in any thread of any app within the JVM can change either the default zone or locale.

Better to always specify explicitly the desired/expected zone or locale by passing optional arguments, rather than rely implicitly on the JVM's current default.

Time zone

A time zone is crucial in determining a date. For any given moment, the date varies around the globe by zone. For example, a few minutes after midnight in Paris France is a new day while still “yesterday” in Montréal Québec .

If no time zone is specified, the JVM implicitly applies its current default time zone. That default may change at any moment, so your results may vary. Better to specify your desired/expected time zone explicitly as an argument.

Specify a proper time zone name in the format of continent/region , such as America/Montreal , Africa/Casablanca , or Pacific/Auckland . Never use the 3-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!).

ZoneId z = ZoneId.of( "America/Montreal" ) ;  
LocalDate today = LocalDate.now( z ) ;

If you want to use the JVM's current default time zone, ask for it and pass as an argument. If omitted, the JVM's current default is applied implicitly. Better to be explicit, as the default may be changed at any moment during runtime by any code in any thread of any app within the JVM.

ZoneId z = ZoneId.systemDefault() ;  // Get JVM’s current default time zone.

Locale

The DateTimeFormatter class can automatically localize when generating a String representing a date-time value.

Instant instant = Instant.now();  // Current moment in UTC with a resolution of up to nanoseconds.
ZoneId z = ZoneId.of( "America/Montreal" ); 
ZonedDateTime zdt = instant.atZone( z );  // Adjust from UTC to a specific time zone. Same moment, different wall-clock time.

To localize, specify:

• FormatStyle to determine how long or abbreviated should the string be.
• Locale to determine (a) the human language for translation of name of day, name of month, and such, and (b) the cultural norms deciding issues of abbreviation, capitalization, punctuation, separators, and such.

Example:

ZoneId z = ZoneId.of( "Pacific/Auckland" ); 
ZonedDateTime zdt = ZonedDateTime.now( z ) ;

Locale l = Locale.CANADA_FRENCH ; 
DateTimeFormatter f = DateTimeFormatter.ofLocalizedDateTime( FormatStyle.FULL ).withLocale( l );
String output = zdt.format( f );

Notes

By the way, note that in date-time handling, the issues of time zone and locale are distinct, orthogonal. The first defines the meaning or content of the date-time value, the second controls its formatting for display. You can have a Québec moment display in Japanese format, or an India moment display in Norwegian format.

Say your development and production servers are set to have TimeZone GMT+2.

Generally speaking, servers should be set to UTC. But as discussed above, never rely on that. Pass your desired/expected time zone as arguments, even if your desire is UTC.

a 2-hour shift may not be easy to observe immediately.

You can now do testing more easily with java.time by passing alternate implementations of Clock class. That class itself provides alternate behaviors such as setting a fixed time, or setting the clock to be so many hours/minutes ahead or behind of true time.

You will likely need to rewrite some code to communicate the zone, locale, or encoding via some sort of dependency-injection . That might be as simple as passing arguments to a section of code.

And although you can pass a TimeZone to your calendars, APIs might be instantiating calendars (or dates) using the default timezone.

Seems to be a very common problem that programmers ignore the issue of time zone and locale. Probably due more often to ignorance than laziness.

No magic bullet here except to:

• Educate your programmers about date-time handling, localizing, and character encoding .
• Set a standard for your team insisting that zone, locale, and character-encoding always be explicit. If the default is desired, make an explicit call to get the default.

I do agree with the sentiment behind your Question. Frameworks and APIs should never provide default values for time zone, locale, and character-encoding , in my humble opinion. Relying on such defaults without thinking by the programmers is a source of some of the most troubling elusive runtime bugs. But, c'est la vie , we have to deal with reality as-is.