1 /* 2 * Copyright (c) 2012, 2018, Oracle and/or its affiliates. All rights reserved. 3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 4 * 5 * This code is free software; you can redistribute it and/or modify it 6 * under the terms of the GNU General Public License version 2 only, as 7 * published by the Free Software Foundation. Oracle designates this 8 * particular file as subject to the "Classpath" exception as provided 9 * by Oracle in the LICENSE file that accompanied this code. 10 * 11 * This code is distributed in the hope that it will be useful, but WITHOUT 12 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 13 * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 14 * version 2 for more details (a copy is included in the LICENSE file that 15 * accompanied this code). 16 * 17 * You should have received a copy of the GNU General Public License version 18 * 2 along with this work; if not, write to the Free Software Foundation, 19 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 20 * 21 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 22 * or visit www.oracle.com if you need additional information or have any 23 * questions. 24 */ 25 26 /* 27 * This file is available under and governed by the GNU General Public 28 * License version 2 only, as published by the Free Software Foundation. 29 * However, the following notice accompanied the original version of this 30 * file: 31 * 32 * Copyright (c) 2012, Stephen Colebourne & Michael Nascimento Santos 33 * 34 * All rights reserved. 35 * 36 * Redistribution and use in source and binary forms, with or without 37 * modification, are permitted provided that the following conditions are met: 38 * 39 * * Redistributions of source code must retain the above copyright notice, 40 * this list of conditions and the following disclaimer. 41 * 42 * * Redistributions in binary form must reproduce the above copyright notice, 43 * this list of conditions and the following disclaimer in the documentation 44 * and/or other materials provided with the distribution. 45 * 46 * * Neither the name of JSR-310 nor the names of its contributors 47 * may be used to endorse or promote products derived from this software 48 * without specific prior written permission. 49 * 50 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 51 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 52 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 53 * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR 54 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 55 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 56 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR 57 * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 58 * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 59 * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 60 * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 61 */ 62 63 /** 64 * <p> 65 * The main API for dates, times, instants, and durations. 66 * </p> 67 * <p> 68 * The classes defined here represent the principle date-time concepts, 69 * including instants, durations, dates, times, time-zones and periods. 70 * They are based on the ISO calendar system, which is the <i>de facto</i> world 71 * calendar following the proleptic Gregorian rules. 72 * All the classes are immutable and thread-safe. 73 * </p> 74 * <p> 75 * Each date time instance is composed of fields that are conveniently 76 * made available by the APIs. For lower level access to the fields refer 77 * to the {@code java.time.temporal} package. 78 * Each class includes support for printing and parsing all manner of dates and times. 79 * Refer to the {@code java.time.format} package for customization options. 80 * </p> 81 * <p> 82 * The {@code java.time.chrono} package contains the calendar neutral API 83 * {@link java.time.chrono.ChronoLocalDate ChronoLocalDate}, 84 * {@link java.time.chrono.ChronoLocalDateTime ChronoLocalDateTime}, 85 * {@link java.time.chrono.ChronoZonedDateTime ChronoZonedDateTime} and 86 * {@link java.time.chrono.Era Era}. 87 * This is intended for use by applications that need to use localized calendars. 88 * It is recommended that applications use the ISO-8601 date and time classes from 89 * this package across system boundaries, such as to the database or across the network. 90 * The calendar neutral API should be reserved for interactions with users. 91 * </p> 92 * 93 * <h2>Dates and Times</h2> 94 * <p> 95 * {@link java.time.Instant} is essentially a numeric timestamp. 96 * The current Instant can be retrieved from a {@link java.time.Clock}. 97 * This is useful for logging and persistence of a point in time 98 * and has in the past been associated with storing the result 99 * from {@link java.lang.System#currentTimeMillis()}. 100 * </p> 101 * <p> 102 * {@link java.time.LocalDate} stores a date without a time. 103 * This stores a date like '2010-12-03' and could be used to store a birthday. 104 * </p> 105 * <p> 106 * {@link java.time.LocalTime} stores a time without a date. 107 * This stores a time like '11:30' and could be used to store an opening or closing time. 108 * </p> 109 * <p> 110 * {@link java.time.LocalDateTime} stores a date and time. 111 * This stores a date-time like '2010-12-03T11:30'. 112 * </p> 113 * <p> 114 * {@link java.time.ZonedDateTime} stores a date and time with a time-zone. 115 * This is useful if you want to perform accurate calculations of 116 * dates and times taking into account the {@link java.time.ZoneId}, such as 'Europe/Paris'. 117 * Where possible, it is recommended to use a simpler class without a time-zone. 118 * The widespread use of time-zones tends to add considerable complexity to an application. 119 * </p> 120 * 121 * <h2>Duration and Period</h2> 122 * <p> 123 * Beyond dates and times, the API also allows the storage of periods and durations of time. 124 * A {@link java.time.Duration} is a simple measure of time along the time-line in nanoseconds. 125 * A {@link java.time.Period} expresses an amount of time in units meaningful 126 * to humans, such as years or days. 127 * </p> 128 * 129 * <h2>Additional value types</h2> 130 * <p> 131 * {@link java.time.Month} stores a month on its own. 132 * This stores a single month-of-year in isolation, such as 'DECEMBER'. 133 * </p> 134 * <p> 135 * {@link java.time.DayOfWeek} stores a day-of-week on its own. 136 * This stores a single day-of-week in isolation, such as 'TUESDAY'. 137 * </p> 138 * <p> 139 * {@link java.time.Year} stores a year on its own. 140 * This stores a single year in isolation, such as '2010'. 141 * </p> 142 * <p> 143 * {@link java.time.YearMonth} stores a year and month without a day or time. 144 * This stores a year and month, such as '2010-12' and could be used for a credit card expiry. 145 * </p> 146 * <p> 147 * {@link java.time.MonthDay} stores a month and day without a year or time. 148 * This stores a month and day-of-month, such as '--12-03' and 149 * could be used to store an annual event like a birthday without storing the year. 150 * </p> 151 * <p> 152 * {@link java.time.OffsetTime} stores a time and offset from UTC without a date. 153 * This stores a date like '11:30+01:00'. 154 * The {@link java.time.ZoneOffset ZoneOffset} is of the form '+01:00'. 155 * </p> 156 * <p> 157 * {@link java.time.OffsetDateTime} stores a date and time and offset from UTC. 158 * This stores a date-time like '2010-12-03T11:30+01:00'. 159 * This is sometimes found in XML messages and other forms of persistence, 160 * but contains less information than a full time-zone. 161 * </p> 162 * 163 * <h2>Package specification</h2> 164 * <p> 165 * Unless otherwise noted, passing a null argument to a constructor or method in any class or interface 166 * in this package will cause a {@link java.lang.NullPointerException NullPointerException} to be thrown. 167 * The Javadoc "@param" definition is used to summarise the null-behavior. 168 * The "@throws {@link java.lang.NullPointerException}" is not explicitly documented in each method. 169 * </p> 170 * <p> 171 * All calculations should check for numeric overflow and throw either an {@link java.lang.ArithmeticException} 172 * or a {@link java.time.DateTimeException}. 173 * </p> 174 * 175 * <h2>Design notes (non normative)</h2> 176 * <p> 177 * The API has been designed to reject null early and to be clear about this behavior. 178 * A key exception is any method that takes an object and returns a boolean, for the purpose 179 * of checking or validating, will generally return false for null. 180 * </p> 181 * <p> 182 * The API is designed to be type-safe where reasonable in the main high-level API. 183 * Thus, there are separate classes for the distinct concepts of date, time and date-time, 184 * plus variants for offset and time-zone. 185 * This can seem like a lot of classes, but most applications can begin with just five date/time types. 186 * <ul> 187 * <li>{@link java.time.Instant} - a timestamp</li> 188 * <li>{@link java.time.LocalDate} - a date without a time, or any reference to an offset or time-zone</li> 189 * <li>{@link java.time.LocalTime} - a time without a date, or any reference to an offset or time-zone</li> 190 * <li>{@link java.time.LocalDateTime} - combines date and time, but still without any offset or time-zone</li> 191 * <li>{@link java.time.ZonedDateTime} - a "full" date-time with time-zone and resolved offset from UTC/Greenwich</li> 192 * </ul> 193 * <p> 194 * {@code Instant} is the closest equivalent class to {@code java.util.Date}. 195 * {@code ZonedDateTime} is the closest equivalent class to {@code java.util.GregorianCalendar}. 196 * </p> 197 * <p> 198 * Where possible, applications should use {@code LocalDate}, {@code LocalTime} and {@code LocalDateTime} 199 * to better model the domain. For example, a birthday should be stored in a code {@code LocalDate}. 200 * Bear in mind that any use of a {@linkplain java.time.ZoneId time-zone}, such as 'Europe/Paris', adds 201 * considerable complexity to a calculation. 202 * Many applications can be written only using {@code LocalDate}, {@code LocalTime} and {@code Instant}, 203 * with the time-zone added at the user interface (UI) layer. 204 * </p> 205 * <p> 206 * The offset-based date-time types {@code OffsetTime} and {@code OffsetDateTime}, 207 * are intended primarily for use with network protocols and database access. 208 * For example, most databases cannot automatically store a time-zone like 'Europe/Paris', but 209 * they can store an offset like '+02:00'. 210 * </p> 211 * <p> 212 * Classes are also provided for the most important sub-parts of a date, including {@code Month}, 213 * {@code DayOfWeek}, {@code Year}, {@code YearMonth} and {@code MonthDay}. 214 * These can be used to model more complex date-time concepts. 215 * For example, {@code YearMonth} is useful for representing a credit card expiry. 216 * </p> 217 * <p> 218 * Note that while there are a large number of classes representing different aspects of dates, 219 * there are relatively few dealing with different aspects of time. 220 * Following type-safety to its logical conclusion would have resulted in classes for 221 * hour-minute, hour-minute-second and hour-minute-second-nanosecond. 222 * While logically pure, this was not a practical option as it would have almost tripled the 223 * number of classes due to the combinations of date and time. 224 * Thus, {@code LocalTime} is used for all precisions of time, with zeroes used to imply lower precision. 225 * </p> 226 * <p> 227 * Following full type-safety to its ultimate conclusion might also argue for a separate class 228 * for each field in date-time, such as a class for HourOfDay and another for DayOfMonth. 229 * This approach was tried, but was excessively complicated in the Java language, lacking usability. 230 * A similar problem occurs with periods. 231 * There is a case for a separate class for each period unit, such as a type for Years and a type for Minutes. 232 * However, this yields a lot of classes and a problem of type conversion. 233 * Thus, the set of date-time types provided is a compromise between purity and practicality. 234 * </p> 235 * <p> 236 * The API has a relatively large surface area in terms of number of methods. 237 * This is made manageable through the use of consistent method prefixes. 238 * <ul> 239 * <li>{@code of} - static factory method</li> 240 * <li>{@code parse} - static factory method focussed on parsing</li> 241 * <li>{@code get} - gets the value of something</li> 242 * <li>{@code is} - checks if something is true</li> 243 * <li>{@code with} - the immutable equivalent of a setter</li> 244 * <li>{@code plus} - adds an amount to an object</li> 245 * <li>{@code minus} - subtracts an amount from an object</li> 246 * <li>{@code to} - converts this object to another type</li> 247 * <li>{@code at} - combines this object with another, such as {@code date.atTime(time)}</li> 248 * </ul> 249 * <p> 250 * Multiple calendar systems is an awkward addition to the design challenges. 251 * The first principle is that most users want the standard ISO calendar system. 252 * As such, the main classes are ISO-only. The second principle is that most of those that want a 253 * non-ISO calendar system want it for user interaction, thus it is a UI localization issue. 254 * As such, date and time objects should be held as ISO objects in the data model and persistent 255 * storage, only being converted to and from a local calendar for display. 256 * The calendar system would be stored separately in the user preferences. 257 * </p> 258 * <p> 259 * There are, however, some limited use cases where users believe they need to store and use 260 * dates in arbitrary calendar systems throughout the application. 261 * This is supported by {@link java.time.chrono.ChronoLocalDate}, however it is vital to read 262 * all the associated warnings in the Javadoc of that interface before using it. 263 * In summary, applications that require general interoperation between multiple calendar systems 264 * typically need to be written in a very different way to those only using the ISO calendar, 265 * thus most applications should just use ISO and avoid {@code ChronoLocalDate}. 266 * </p> 267 * <p> 268 * The API is also designed for user extensibility, as there are many ways of calculating time. 269 * The {@linkplain java.time.temporal.TemporalField field} and {@linkplain java.time.temporal.TemporalUnit unit} 270 * API, accessed via {@link java.time.temporal.TemporalAccessor TemporalAccessor} and 271 * {@link java.time.temporal.Temporal Temporal} provide considerable flexibility to applications. 272 * In addition, the {@link java.time.temporal.TemporalQuery TemporalQuery} and 273 * {@link java.time.temporal.TemporalAdjuster TemporalAdjuster} interfaces provide day-to-day 274 * power, allowing code to read close to business requirements: 275 * </p> 276 * <pre> 277 * LocalDate customerBirthday = customer.loadBirthdayFromDatabase(); 278 * LocalDate today = LocalDate.now(); 279 * if (customerBirthday.equals(today)) { 280 * LocalDate specialOfferExpiryDate = today.plusWeeks(2).with(next(FRIDAY)); 281 * customer.sendBirthdaySpecialOffer(specialOfferExpiryDate); 282 * } 283 * 284 * </pre> 285 * 286 * @since 1.8 287 */ 288 package java.time; 289