📄 calendar.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN""http://www.w3.org/TR/REC-html40/frameset.dtd"><!--NewPage--><HTML><HEAD><!-- Generated by javadoc on Thu Apr 27 23:36:51 PDT 2000 --><TITLE>Java 2 Platform SE v1.3: Class Calendar</TITLE><LINK REL ="stylesheet" TYPE="text/css" HREF="../../stylesheet.css" TITLE="Style"></HEAD><BODY BGCOLOR="white"><!-- ========== START OF NAVBAR ========== --><A NAME="navbar_top"><!-- --></A><TABLE BORDER="0" WIDTH="100%" CELLPADDING="1" CELLSPACING="0"><TR><TD COLSPAN=2 BGCOLOR="#EEEEFF" CLASS="NavBarCell1"><A NAME="navbar_top_firstrow"><!-- --></A><TABLE BORDER="0" CELLPADDING="0" CELLSPACING="3"> <TR ALIGN="center" VALIGN="top"> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../overview-summary.html"><FONT CLASS="NavBarFont1"><B>Overview</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="package-summary.html"><FONT CLASS="NavBarFont1"><B>Package</B></FONT></A> </TD> <TD BGCOLOR="#FFFFFF" CLASS="NavBarCell1Rev"> <FONT CLASS="NavBarFont1Rev"><B>Class</B></FONT> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="class-use/Calendar.html"><FONT CLASS="NavBarFont1"><B>Use</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="package-tree.html"><FONT CLASS="NavBarFont1"><B>Tree</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../deprecated-list.html"><FONT CLASS="NavBarFont1"><B>Deprecated</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../index-files/index-1.html"><FONT CLASS="NavBarFont1"><B>Index</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../help-doc.html"><FONT CLASS="NavBarFont1"><B>Help</B></FONT></A> </TD> </TR></TABLE></TD><TD ALIGN="right" VALIGN="top" ROWSPAN=3><EM><b>Java<sup><font size=-2>TM</font></sup> 2 Platform<br>Std. Ed. v1.3</b></EM></TD></TR><TR><TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2"> <A HREF="../../java/util/BitSet.html"><B>PREV CLASS</B></A> <A HREF="../../java/util/Collections.html"><B>NEXT CLASS</B></A></FONT></TD><TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2"> <A HREF="../../index.html" TARGET="_top"><B>FRAMES</B></A> <A HREF="Calendar.html" TARGET="_top"><B>NO FRAMES</B></A></FONT></TD></TR><TR><TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2"> SUMMARY: INNER | <A HREF="#field_summary">FIELD</A> | <A HREF="#constructor_summary">CONSTR</A> | <A HREF="#method_summary">METHOD</A></FONT></TD><TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">DETAIL: <A HREF="#field_detail">FIELD</A> | <A HREF="#constructor_detail">CONSTR</A> | <A HREF="#method_detail">METHOD</A></FONT></TD></TR></TABLE><!-- =========== END OF NAVBAR =========== --><HR><!-- ======== START OF CLASS DATA ======== --><H2><FONT SIZE="-1">java.util</FONT><BR>Class Calendar</H2><PRE><A HREF="../../java/lang/Object.html">java.lang.Object</A> | +--<B>java.util.Calendar</B></PRE><DL><DT><B>All Implemented Interfaces:</B> <DD><A HREF="../../java/lang/Cloneable.html">Cloneable</A>, <A HREF="../../java/io/Serializable.html">Serializable</A></DD></DL><DL><DT><B>Direct Known Subclasses:</B> <DD><A HREF="../../java/util/GregorianCalendar.html">GregorianCalendar</A></DD></DL><HR><DL><DT>public abstract class <B>Calendar</B><DT>extends <A HREF="../../java/lang/Object.html">Object</A><DT>implements <A HREF="../../java/io/Serializable.html">Serializable</A>, <A HREF="../../java/lang/Cloneable.html">Cloneable</A></DL><P><code>Calendar</code> is an abstract base class for converting between a <code>Date</code> object and a set of integer fields such as <code>YEAR</code>, <code>MONTH</code>, <code>DAY</code>, <code>HOUR</code>, and so on. (A <code>Date</code> object represents a specific instant in time with millisecond precision. See <A HREF="../../java/util/Date.html"><CODE>Date</CODE></A> for information about the <code>Date</code> class.) <p> Subclasses of <code>Calendar</code> interpret a <code>Date</code> according to the rules of a specific calendar system. The platform provides one concrete subclass of <code>Calendar</code>: <code>GregorianCalendar</code>. Future subclasses could represent the various types of lunar calendars in use in many parts of the world. <p> Like other locale-sensitive classes, <code>Calendar</code> provides a class method, <code>getInstance</code>, for getting a generally useful object of this type. <code>Calendar</code>'s <code>getInstance</code> method returns a <code>GregorianCalendar</code> object whose time fields have been initialized with the current date and time: <blockquote> <pre> Calendar rightNow = Calendar.getInstance(); </pre> </blockquote> <p>A <code>Calendar</code> object can produce all the time field values needed to implement the date-time formatting for a particular language and calendar style (for example, Japanese-Gregorian, Japanese-Traditional). <code>Calendar</code> defines the range of values returned by certain fields, as well as their meaning. For example, the first month of the year has value <code>MONTH</code> == <code>JANUARY</code> for all calendars. Other values are defined by the concrete subclass, such as <code>ERA</code> and <code>YEAR</code>. See individual field documentation and subclass documentation for details. <p>When a <code>Calendar</code> is <em>lenient</em>, it accepts a wider range of field values than it produces. For example, a lenient <code>GregorianCalendar</code> interprets <code>MONTH</code> == <code>JANUARY</code>, <code>DAY_OF_MONTH</code> == 32 as February 1. A non-lenient <code>GregorianCalendar</code> throws an exception when given out-of-range field settings. When calendars recompute field values for return by <code>get()</code>, they normalize them. For example, a <code>GregorianCalendar</code> always produces <code>DAY_OF_MONTH</code> values between 1 and the length of the month. <p><code>Calendar</code> defines a locale-specific seven day week using two parameters: the first day of the week and the minimal days in first week (from 1 to 7). These numbers are taken from the locale resource data when a <code>Calendar</code> is constructed. They may also be specified explicitly through the API. <p>When setting or getting the <code>WEEK_OF_MONTH</code> or <code>WEEK_OF_YEAR</code> fields, <code>Calendar</code> must determine the first week of the month or year as a reference point. The first week of a month or year is defined as the earliest seven day period beginning on <code>getFirstDayOfWeek()</code> and containing at least <code>getMinimalDaysInFirstWeek()</code> days of that month or year. Weeks numbered ..., -1, 0 precede the first week; weeks numbered 2, 3,... follow it. Note that the normalized numbering returned by <code>get()</code> may be different. For example, a specific <code>Calendar</code> subclass may designate the week before week 1 of a year as week <em>n</em> of the previous year. <p> When computing a <code>Date</code> from time fields, two special circumstances may arise: there may be insufficient information to compute the <code>Date</code> (such as only year and month but no day in the month), or there may be inconsistent information (such as "Tuesday, July 15, 1996" -- July 15, 1996 is actually a Monday). <p> <strong>Insufficient information.</strong> The calendar will use default information to specify the missing fields. This may vary by calendar; for the Gregorian calendar, the default for a field is the same as that of the start of the epoch: i.e., YEAR = 1970, MONTH = JANUARY, DATE = 1, etc. <p> <strong>Inconsistent information.</strong> If fields conflict, the calendar will give preference to fields set more recently. For example, when determining the day, the calendar will look for one of the following combinations of fields. The most recent combination, as determined by the most recently set single field, will be used. <blockquote> <pre> MONTH + DAY_OF_MONTH MONTH + WEEK_OF_MONTH + DAY_OF_WEEK MONTH + DAY_OF_WEEK_IN_MONTH + DAY_OF_WEEK DAY_OF_YEAR DAY_OF_WEEK + WEEK_OF_YEAR </pre> </blockquote> For the time of day: <blockquote> <pre> HOUR_OF_DAY AM_PM + HOUR </pre> </blockquote> <p> <strong>Note:</strong> for some non-Gregorian calendars, different fields may be necessary for complete disambiguation. For example, a full specification of the historial Arabic astronomical calendar requires year, month, day-of-month <em>and</em> day-of-week in some cases. <p> <strong>Note:</strong> There are certain possible ambiguities in interpretation of certain singular times, which are resolved in the following ways: <ol> <li> 24:00:00 "belongs" to the following day. That is, 23:59 on Dec 31, 1969 < 24:00 on Jan 1, 1970 < 24:01:00 on Jan 1, 1970 <li> Although historically not precise, midnight also belongs to "am", and noon belongs to "pm", so on the same day, 12:00 am (midnight) < 12:01 am, and 12:00 pm (noon) < 12:01 pm </ol> <p> The date or time format strings are not part of the definition of a calendar, as those must be modifiable or overridable by the user at runtime. Use <A HREF="../../java/text/DateFormat.html"><CODE>DateFormat</CODE></A> to format dates. <p><strong>Field manipulation methods</strong></p> <p><code>Calendar</code> fields can be changed using three methods: <code>set()</code>, <code>add()</code>, and <code>roll()</code>.</p> <p><strong><code>set(f, value)</code></strong> changes field <code>f</code> to <code>value</code>. In addition, it sets an internal member variable to indicate that field <code>f</code> has been changed. Although field <code>f</code> is changed immediately, the calendar's milliseconds is not recomputed until the next call to <code>get()</code>, <code>getTime()</code>, or <code>getTimeInMillis()</code> is made. Thus, multiple calls to <code>set()</code> do not trigger multiple, unnecessary computations. As a result of changing a field using <code>set()</code>, other fields may also change, depending on the field, the field value, and the calendar system. In addition, <code>get(f)</code> will not necessarily return <code>value</code> after the fields have been recomputed. The specifics are determined by the concrete calendar class.</p> <p><em>Example</em>: Consider a <code>GregorianCalendar</code> originally set to August 31, 1999. Calling <code>set(Calendar.MONTH, Calendar.SEPTEMBER)</code> sets the calendar to September 31, 1999. This is a temporary internal representation that resolves to October 1, 1999 if <code>getTime()</code>is then called. However, a call to <code>set(Calendar.DAY_OF_MONTH, 30)</code> before the call to <code>getTime()</code> sets the calendar to September 30, 1999, since no recomputation occurs after <code>set()</code> itself.</p> <p><strong><code>add(f, delta)</code></strong> adds <code>delta</code> to field <code>f</code>. This is equivalent to calling <code>set(f, get(f) + delta)</code> with two adjustments:</p> <blockquote> <p><strong>Add rule 1</strong>. The value of field <code>f</code> after the call minus the value of field <code>f</code> before the call is <code>delta</code>, modulo any overflow that has occurred in field <code>f</code>. Overflow occurs when a field value exceeds its range and, as a result, the next larger field is incremented or decremented and the field value is adjusted back into its range.</p> <p><strong>Add rule 2</strong>. If a smaller field is expected to be invariant, but it is impossible for it to be equal to its prior value because of changes in its minimum or maximum after field <code>f</code> is changed, then its value is adjusted to be as close as possible to its expected value. A smaller field represents a smaller unit of time. <code>HOUR</code> is a smaller field than <code>DAY_OF_MONTH</code>. No adjustment is made to smaller fields that are not expected to be invariant. The calendar system determines what fields are expected to be invariant.</p> </blockquote> <p>In addition, unlike <code>set()</code>, <code>add()</code> forces an immediate recomputation of the calendar's milliseconds and all fields.</p> <p><em>Example</em>: Consider a <code>GregorianCalendar</code> originally set to August 31, 1999. Calling <code>add(Calendar.MONTH, 13)</code> sets the calendar to September 30, 2000. <strong>Add rule 1</strong> sets the <code>MONTH</code> field to September, since adding 13 months to August gives September of the next year. Since <code>DAY_OF_MONTH</code> cannot be 31 in September in a <code>GregorianCalendar</code>, <strong>add rule 2</strong> sets the <code>DAY_OF_MONTH</code> to 30, the closest possible value. Although it is a smaller field, <code>DAY_OF_WEEK</code> is not adjusted by rule 2, since it is expected to change when the month changes in a <code>GregorianCalendar</code>.</p> <p><strong><code>roll(f, delta)</code></strong> adds <code>delta</code> to field <code>f</code> without changing larger fields. This is equivalent to calling <code>add(f, delta)</code> with the following adjustment:</p> <blockquote> <p><strong>Roll rule</strong>. Larger fields are unchanged after the call. A larger field represents a larger unit of time. <code>DAY_OF_MONTH</code> is a larger field than <code>HOUR</code>.</p> </blockquote> <p><em>Example</em>: Consider a <code>GregorianCalendar</code> originally set to August 31, 1999. Calling <code>roll(Calendar.MONTH, 8)</code> sets the calendar to April 30, <strong>1999</strong>. Add rule 1 sets the <code>MONTH</code> field to April. Using a <code>GregorianCalendar</code>, the <code>DAY_OF_MONTH</code> cannot⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -