src/share/classes/java/time/overview.html

Print this page

        

@@ -86,16 +86,10 @@
         By contrast, fields are mini-calculations, defining a value.
         For example, month-of-year, day-of-week and hour-of-day are all fields.
         The set of supported units and fields can be extended by applications if desired.
     </p>
     <p>
-        It also contains the basic part of the calendar neutral API.
-        This is intended for use by applications that need to use localized calendars.
-        Ensure that you read the class documentation of {@link java.time.temporal.ChronoLocalDate}
-        before using non-ISO calendar systems.
-    </p>
-    <p>
         {@link java.time.format} contains the API to print and parse fields into date-time
         objects and to customize parsing and printing.
         Formatters can be created in a variety of ways, including constants, patterns,
         localized styles and a builder.
         Formatters are immutable and thread-safe.

@@ -103,11 +97,12 @@
     <p>
         {@link java.time.zone} contains the API to handle time-zones.
         Detailed information is made available about the rules of each time-zone.
     </p>
     <p>
-        The {@link java.time.calendar} package contains alternate calendar systems.
+        {@link java.time.chrono} contains the basic part of the calendar neutral API
+        and alternate calendar systems.
         This is intended for use by applications that need to use localized calendars.
         Support is provided for the Hijrah, Japanese, Minguo, and Thai Buddhist Calendars.
     </p>
     <h3>Design notes</h3>
     <p>

@@ -134,11 +129,11 @@
         hour-minute, hour-minute-second and hour-minute-second-nanosecond.
         While logically pure, this was not possible in practice, as the additional classes would have
         excessively complicated the API. Notably, there would be additional combinations at the offset
         and date-time levels, such as offset-date-hour-minute.
         To avoid this explosion of types, {@link java.time.LocalTime} is used for all precisions of time.
-        By contrast, some additional classes were used for dates, such as {@link java.time.temporal.YearMonth}.
+        By contrast, some additional classes were used for dates, such as {@link java.time.YearMonth}.
         This proved necessary, as the API for year-month is significantly different to that for a date, whereas
         an absence of nanoseconds in a time can be approximated by returning zero.
     </p>
     <p>
         Similarly, full type-safety might argue for a separate class for each field in date-time,

@@ -159,11 +154,11 @@
         The calendar system would be stored separately in the user preferences.
     </p>
     <p>
         There are, however, some limited use cases where users believe they need to store and use
         dates in arbitrary calendar systems throughout the application.
-        This is supported by {@link java.time.temporal.ChronoLocalDate}, however it is vital to read
+        This is supported by {@link java.time.chrono.ChronoLocalDate}, however it is vital to read
         all the associated warnings in the Javadoc of that interface before using it.
         In summary, applications that require general interoperation between multiple calendar systems
         typically need to be written in a very different way to those only using the ISO calendar,
         thus most applications should just use ISO and avoid {@code ChronoLocalDate}.
     </p>