Purpose Joda Time LocalDate (Object instant, DateTimeZone zone) constructor

Question

Joda LocalDate describes itself as:

LocalDate is an immutable datetime class that represents a date without a time zone.

However, there is a LocalDate(Object instant, DateTimeZone zone) constructor LocalDate(Object instant, DateTimeZone zone) that accepts a time zone. If the object is smaller than in the time zone, what is the purpose of the time zone constructor?

The JavaDocs constructor states:

Creates an instance of an object representing the date and time, forcing the time zone specified.

I do not know what is meant by “forcing the time zone to be specified”, since the object does not have a time zone. Perhaps it internally converts to UTC, then discards the time (saves the date).

Answer 1

You cannot instantly convert to a local date or time without knowing the time zone (or at least the offset from UTC / Greenwich). Since the first argument is instantaneous (for example, Long or java.util.Date , the second argument is needed to indicate the time zone used.

Note that there is also a LocalDate(Object) constructor that uses the default inner zone.

Answer 2

instantaneous is a concept from the field of physics. This is a point in time , clearly defined, regardless of how you represent it. This has nothing to do with time zones, calendars or any conventions of human culture.

Examples: the moment when Apollo XI landed on the Moon , or the moment when John F. Kennedy was shot, are moments. Each of them can be represented in several ways: the Julian calendar, the seconds elapsed from the moment the “Titanic” hit the iceberg, some calendar used by some extraneous creature living on Mars ... all of these would be different representations , but the moment would be unique (just like 1903 , 0x76F or MCMIII - different representations of the same number).

Now, if you want to convert the “moment of landing of the Apollo XI Moon” to LocalDate (the day-month-year used in the Gregorian calendars on Earth), you are going to a completely different realm, and for one you need to know the time zone, because in some in countries, this moment (July 20, 1969, 20:17:40 UTC) corresponds to July 20, 1969, in others until July 21

Answer 3

You should read the whole JavaDoc:

If the object does not contain a chronology, ISOChronology is used. If the specified time zone is null, the default zone is used. Once the constructor is completed, the zone is no longer used.

Specific object types are defined in ConverterManager and include ReadablePartial, ReadableInstant, String, Calendar, and Date. String formats are described by ISODateTimeFormat.localDateParser (). The String converter ignores the zone by default and parses only the field values.

Thus, date representations (String, Calendar, Date, etc.) along with the specified time zone give you local time.

If, for example, you have a date representation of java.util.Date , then the local time depends on the time zone. By specifying the time zone, you determine the local time.

Answer 4

(In response to JodaStephen)

Note that there is also a LocalDate(Object) constructor that uses the default inner zone.

Remember that if you use constructors with java.util.Date as the instantaneous time, then the "default time zone" will be UTC, NOT the default JVM time zone , as some have expected (I assumed that creating a LocalDate from java.util.Date or its native "yyyy-MM-dd" will mean the same thing, and since java.util.Date.toString() uses the JVM default timezone ...)

So, in order to properly convert the created java.util.Date without worrying about time zones (for example, just by analyzing the string "yyyy-MM-dd") on LocalDate , you should do something like this:

 LocalDate localDate = new LocalDate(javaUtilDate, DateTimeZone.forTimeZone(TimeZone.getDefault())); 

This is true for JodaTime 2.2 at least; we are debugging the code.