+// © 2016 and later: Unicode, Inc. and others.
+// License & terms of use: http://www.unicode.org/copyright.html
/*
********************************************************************************
-* Copyright (C) 1997-2012, International Business Machines
+* Copyright (C) 1997-2014, International Business Machines
* Corporation and others. All Rights Reserved.
********************************************************************************
*
#include "unicode/ucal.h"
#include "unicode/umisc.h"
+#if U_SHOW_CPLUSPLUS_API
U_NAMESPACE_BEGIN
class ICUServiceFactory;
* and calendar style (for example, Japanese-Gregorian, Japanese-Traditional).
*
* <p>
- * When computing a <code>UDate</code> from time fields, two special circumstances
+ * When computing a <code>UDate</code> from time fields, some special circumstances
* may arise: there may be insufficient information to compute the
* <code>UDate</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).
+ * there may be inconsistent information (such as "Tuesday, July 15, 1996"
+ * -- July 15, 1996 is actually a Monday), or the input time might be ambiguous
+ * because of time zone transition.
*
* <p>
* <strong>Insufficient information.</strong> The calendar will use default
* \htmlonly</blockquote>\endhtmlonly
*
* <p>
+ * <strong>Ambiguous Wall Clock Time.</strong> When time offset from UTC has
+ * changed, it produces an ambiguous time slot around the transition. For example,
+ * many US locations observe daylight saving time. On the date switching to daylight
+ * saving time in US, wall clock time jumps from 12:59 AM (standard) to 2:00 AM
+ * (daylight). Therefore, wall clock time from 1:00 AM to 1:59 AM do not exist on
+ * the date. When the input wall time fall into this missing time slot, the ICU
+ * Calendar resolves the time using the UTC offset before the transition by default.
+ * In this example, 1:30 AM is interpreted as 1:30 AM standard time (non-exist),
+ * so the final result will be 2:30 AM daylight time.
+ *
+ * <p>On the date switching back to standard time, wall clock time is moved back one
+ * hour at 2:00 AM. So wall clock time from 1:00 AM to 1:59 AM occur twice. In this
+ * case, the ICU Calendar resolves the time using the UTC offset after the transition
+ * by default. For example, 1:30 AM on the date is resolved as 1:30 AM standard time.
+ *
+ * <p>Ambiguous wall clock time resolution behaviors can be customized by Calendar APIs
+ * {@link #setRepeatedWallTimeOption} and {@link #setSkippedWallTimeOption}.
+ * These methods are available in ICU 49 or later versions.
+ *
+ * <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,
* For example, subtracting 5 days from the date <code>September 12, 1996</code>
* results in <code>September 7, 1996</code>.
*
+ * <p><big><b>Supported range</b></big>
+ *
+ * <p>The allowable range of <code>Calendar</code> has been
+ * narrowed. <code>GregorianCalendar</code> used to attempt to support
+ * the range of dates with millisecond values from
+ * <code>Long.MIN_VALUE</code> to <code>Long.MAX_VALUE</code>.
+ * The new <code>Calendar</code> protocol specifies the
+ * maximum range of supportable dates as those having Julian day numbers
+ * of <code>-0x7F000000</code> to <code>+0x7F000000</code>. This
+ * corresponds to years from ~5,800,000 BCE to ~5,800,000 CE. Programmers
+ * should use the protected constants in <code>Calendar</code> to
+ * specify an extremely early or extremely late date.</p>
+ *
* @stable ICU 2.0
*/
class U_I18N_API Calendar : public UObject {
* Gets a Calendar using the given timezone and given locale. The TimeZone
* is _not_ adopted; the client is still responsible for deleting it.
*
- * @param zoneToAdopt The given timezone to be adopted.
+ * @param zone The given timezone.
* @param aLocale The given locale.
* @param success Indicates the success/failure of Calendar creation. Filled in
* with U_ZERO_ERROR if created successfully, set to a failure result
* @return A Calendar if created successfully. NULL otherwise.
* @stable ICU 2.0
*/
- static Calendar* U_EXPORT2 createInstance(const TimeZone& zoneToAdopt, const Locale& aLocale, UErrorCode& success);
+ static Calendar* U_EXPORT2 createInstance(const TimeZone& zone, const Locale& aLocale, UErrorCode& success);
/**
* Returns a list of the locales for which Calendars are installed.
* the month or Calendar::MONTH field, other fields like date might conflict and
* need to be changed. For instance, adding 1 month on the date 01/31/96 will result
* in 02/29/96.
+ * Adding a positive value always means moving forward in time, so for the Gregorian calendar,
+ * starting with 100 BC and adding +1 to year results in 99 BC (even though this actually reduces
+ * the numeric value of the field itself).
*
* @param field Specifies which date field to modify.
* @param amount The amount of time to be added to the field, in the natural unit
* the month or Calendar::MONTH field, other fields like date might conflict and
* need to be changed. For instance, adding 1 month on the date 01/31/96 will result
* in 02/29/96.
+ * Adding a positive value always means moving forward in time, so for the Gregorian calendar,
+ * starting with 100 BC and adding +1 to year results in 99 BC (even though this actually reduces
+ * the numeric value of the field itself).
*
* @param field Specifies which date field to modify.
* @param amount The amount of time to be added to the field, in the natural unit
* value returned by getMaximum(Calendar::YEAR). When rolling on the month or
* Calendar::MONTH field, other fields like date might conflict and, need to be
* changed. For instance, rolling the month up on the date 01/31/96 will result in
- * 02/29/96. Rolling up always means rolling forward in time; e.g., rolling the year
- * up on "100 BC" will result in "99 BC", for Gregorian calendar. When rolling on the
- * hour-in-day or Calendar::HOUR_OF_DAY field, it will roll the hour value in the range
- * between 0 and 23, which is zero-based.
+ * 02/29/96. Rolling up always means rolling forward in time (unless the limit of the
+ * field is reached, in which case it may pin or wrap), so for Gregorian calendar,
+ * starting with 100 BC and rolling the year up results in 99 BC.
+ * When eras have a definite beginning and end (as in the Chinese calendar, or as in
+ * most eras in the Japanese calendar) then rolling the year past either limit of the
+ * era will cause the year to wrap around. When eras only have a limit at one end,
+ * then attempting to roll the year past that limit will result in pinning the year
+ * at that limit. Note that for most calendars in which era 0 years move forward in
+ * time (such as Buddhist, Hebrew, or Islamic), it is possible for add or roll to
+ * result in negative years for era 0 (that is the only way to represent years before
+ * the calendar epoch).
+ * When rolling on the hour-in-day or Calendar::HOUR_OF_DAY field, it will roll the
+ * hour value in the range between 0 and 23, which is zero-based.
* <P>
* NOTE: Do not use this method -- use roll(EDateFields, int, UErrorCode&) instead.
*
* value returned by getMaximum(Calendar::YEAR). When rolling on the month or
* Calendar::MONTH field, other fields like date might conflict and, need to be
* changed. For instance, rolling the month up on the date 01/31/96 will result in
- * 02/29/96. Rolling up always means rolling forward in time; e.g., rolling the year
- * up on "100 BC" will result in "99 BC", for Gregorian calendar. When rolling on the
- * hour-in-day or Calendar::HOUR_OF_DAY field, it will roll the hour value in the range
- * between 0 and 23, which is zero-based.
+ * 02/29/96. Rolling up always means rolling forward in time (unless the limit of the
+ * field is reached, in which case it may pin or wrap), so for Gregorian calendar,
+ * starting with 100 BC and rolling the year up results in 99 BC.
+ * When eras have a definite beginning and end (as in the Chinese calendar, or as in
+ * most eras in the Japanese calendar) then rolling the year past either limit of the
+ * era will cause the year to wrap around. When eras only have a limit at one end,
+ * then attempting to roll the year past that limit will result in pinning the year
+ * at that limit. Note that for most calendars in which era 0 years move forward in
+ * time (such as Buddhist, Hebrew, or Islamic), it is possible for add or roll to
+ * result in negative years for era 0 (that is the only way to represent years before
+ * the calendar epoch).
+ * When rolling on the hour-in-day or Calendar::HOUR_OF_DAY field, it will roll the
+ * hour value in the range between 0 and 23, which is zero-based.
* <P>
* NOTE: Do not use this method -- use roll(UCalendarDateFields, int, UErrorCode&) instead.
*
* roll(Calendar::DATE, +1, status). When rolling on the month or
* Calendar::MONTH field, other fields like date might conflict and, need to be
* changed. For instance, rolling the month up on the date 01/31/96 will result in
- * 02/29/96. Rolling by a positive value always means rolling forward in time;
- * e.g., rolling the year by +1 on "100 BC" will result in "99 BC", for Gregorian
- * calendar. When rolling on the hour-in-day or Calendar::HOUR_OF_DAY field, it will
- * roll the hour value in the range between 0 and 23, which is zero-based.
+ * 02/29/96. Rolling by a positive value always means rolling forward in time (unless
+ * the limit of the field is reached, in which case it may pin or wrap), so for
+ * Gregorian calendar, starting with 100 BC and rolling the year by + 1 results in 99 BC.
+ * When eras have a definite beginning and end (as in the Chinese calendar, or as in
+ * most eras in the Japanese calendar) then rolling the year past either limit of the
+ * era will cause the year to wrap around. When eras only have a limit at one end,
+ * then attempting to roll the year past that limit will result in pinning the year
+ * at that limit. Note that for most calendars in which era 0 years move forward in
+ * time (such as Buddhist, Hebrew, or Islamic), it is possible for add or roll to
+ * result in negative years for era 0 (that is the only way to represent years before
+ * the calendar epoch).
+ * When rolling on the hour-in-day or Calendar::HOUR_OF_DAY field, it will roll the
+ * hour value in the range between 0 and 23, which is zero-based.
* <P>
* The only difference between roll() and add() is that roll() does not change
* the value of more significant fields when it reaches the minimum or maximum
* roll(Calendar::DATE, +1, status). When rolling on the month or
* Calendar::MONTH field, other fields like date might conflict and, need to be
* changed. For instance, rolling the month up on the date 01/31/96 will result in
- * 02/29/96. Rolling by a positive value always means rolling forward in time;
- * e.g., rolling the year by +1 on "100 BC" will result in "99 BC", for Gregorian
- * calendar. When rolling on the hour-in-day or Calendar::HOUR_OF_DAY field, it will
- * roll the hour value in the range between 0 and 23, which is zero-based.
+ * 02/29/96. Rolling by a positive value always means rolling forward in time (unless
+ * the limit of the field is reached, in which case it may pin or wrap), so for
+ * Gregorian calendar, starting with 100 BC and rolling the year by + 1 results in 99 BC.
+ * When eras have a definite beginning and end (as in the Chinese calendar, or as in
+ * most eras in the Japanese calendar) then rolling the year past either limit of the
+ * era will cause the year to wrap around. When eras only have a limit at one end,
+ * then attempting to roll the year past that limit will result in pinning the year
+ * at that limit. Note that for most calendars in which era 0 years move forward in
+ * time (such as Buddhist, Hebrew, or Islamic), it is possible for add or roll to
+ * result in negative years for era 0 (that is the only way to represent years before
+ * the calendar epoch).
+ * When rolling on the hour-in-day or Calendar::HOUR_OF_DAY field, it will roll the
+ * hour value in the range between 0 and 23, which is zero-based.
* <P>
* The only difference between roll() and add() is that roll() does not change
* the value of more significant fields when it reaches the minimum or maximum
*/
UBool isLenient(void) const;
-#ifndef U_HIDE_DRAFT_API
/**
* Sets the behavior for handling wall time repeating multiple times
* at negative time zone offset transitions. For example, 1:30 AM on
* @param option the behavior for handling repeating wall time, either
* <code>UCAL_WALLTIME_FIRST</code> or <code>UCAL_WALLTIME_LAST</code>.
* @see #getRepeatedWallTimeOption
- * @draft ICU 49
+ * @stable ICU 49
*/
void setRepeatedWallTimeOption(UCalendarWallTimeOption option);
* @return the behavior for handling repeating wall time, either
* <code>UCAL_WALLTIME_FIRST</code> or <code>UCAL_WALLTIME_LAST</code>.
* @see #setRepeatedWallTimeOption
- * @draft ICU 49
+ * @stable ICU 49
*/
UCalendarWallTimeOption getRepeatedWallTimeOption(void) const;
* <code>UCAL_WALLTIME_NEXT_VALID</code>.
* @see #getSkippedWallTimeOption
*
- * @draft ICU 49
+ * @stable ICU 49
*/
void setSkippedWallTimeOption(UCalendarWallTimeOption option);
* <code>UCAL_WALLTIME_FIRST</code>, <code>UCAL_WALLTIME_LAST</code>
* and <code>UCAL_WALLTIME_NEXT_VALID</code>.
* @see #setSkippedWallTimeOption
- * @draft ICU 49
+ * @stable ICU 49
*/
UCalendarWallTimeOption getSkippedWallTimeOption(void) const;
-#endif /* U_HIDE_DRAFT_API */
#ifndef U_HIDE_DEPRECATED_API
/**
/**
* Clears the values of all the time fields, making them both unset and assigning
- * them a value of zero. The field values will be determined during the next
- * resolving of time into time fields.
+ * them a value of zero (except for era in some cases, see below). The field values
+ * will be determined during the next resolving of time into time fields.
+ *
+ * This effectively results in the following:
+ * 1. Gregorian-like calendars (gregorian, iso8601, japanese, buddhist, roc) are set
+ * to a UDate value of 0, corresponding to the epoch date of gregorian
+ * January 1, 1970 CE at UTC 00:00:00.
+ * 2. Other calendars are set to the beginning of the first day of the first month of
+ * the current era. Note that for the chinese and dangi calendars, the era
+ * corresponds to the current 60-year stem-branch cycle, so there is a new era
+ * every 60 years. The current era began on gregorian February 2, 1984.
* @stable ICU 2.0
*/
void clear(void);
* \endcode
*
* @return legacy calendar type name string
- * @draft ICU 49
+ * @stable ICU 49
*/
virtual const char * getType() const = 0;
/**
- * Returns whether the given day of the week is a weekday, a
- * weekend day, or a day that transitions from one to the other,
- * in this calendar system. If a transition occurs at midnight,
+ * Returns whether the given day of the week is a weekday, a weekend day,
+ * or a day that transitions from one to the other, for the locale and
+ * calendar system associated with this Calendar (the locale's region is
+ * often the most determinant factor). If a transition occurs at midnight,
* then the days before and after the transition will have the
* type UCAL_WEEKDAY or UCAL_WEEKEND. If a transition occurs at a time
* other than midnight, then the day of the transition will have
/**
* Returns the time during the day at which the weekend begins or ends in
- * this calendar system. If getDayOfWeekType() rerturns UCAL_WEEKEND_ONSET
+ * this calendar system. If getDayOfWeekType() returns UCAL_WEEKEND_ONSET
* for the specified dayOfWeek, return the time at which the weekend begins.
* If getDayOfWeekType() returns UCAL_WEEKEND_CEASE for the specified dayOfWeek,
* return the time at which the weekend ends. If getDayOfWeekType() returns
* @internal
*/
enum ELimitType {
+#ifndef U_HIDE_INTERNAL_API
UCAL_LIMIT_MINIMUM = 0,
UCAL_LIMIT_GREATEST_MINIMUM,
UCAL_LIMIT_LEAST_MAXIMUM,
UCAL_LIMIT_MAXIMUM,
UCAL_LIMIT_COUNT
+#endif /* U_HIDE_INTERNAL_API */
};
/**
* (YEAR_WOY and WEEK_OF_YEAR) to an extended year in the case
* where YEAR, EXTENDED_YEAR are not set.
* The Calendar implementation assumes yearWoy is in extended gregorian form
- * @internal
* @return the extended year, UCAL_EXTENDED_YEAR
+ * @internal
*/
virtual int32_t handleGetExtendedYearFromWeekFields(int32_t yearWoy, int32_t woy);
+ /**
+ * Validate a single field of this calendar. Subclasses should
+ * override this method to validate any calendar-specific fields.
+ * Generic fields can be handled by
+ * <code>Calendar::validateField()</code>.
+ * @see #validateField(int, int, int, int&)
+ * @internal
+ */
+ virtual void validateField(UCalendarDateFields field, UErrorCode &status);
+
#ifndef U_HIDE_INTERNAL_API
/**
* Compute the Julian day from fields. Will determine whether to use
/**
* Time zone affects the time calculation done by Calendar. Calendar subclasses use
- * the time zone data to produce the local time.
+ * the time zone data to produce the local time. Always set; never NULL.
*/
TimeZone* fZone;
*/
void validateFields(UErrorCode &status);
- /**
- * Validate a single field of this calendar. Subclasses should
- * override this method to validate any calendar-specific fields.
- * Generic fields can be handled by
- * <code>Calendar::validateField()</code>.
- * @see #validateField(int, int, int, int&)
- * @internal
- */
- virtual void validateField(UCalendarDateFields field, UErrorCode &status);
-
/**
* Validate a single field of this calendar given its minimum and
* maximum allowed value. If the field is out of range,
/**
* Register a new Calendar factory. The factory will be adopted.
* INTERNAL in 2.6
+ *
+ * Because ICU may choose to cache Calendars internally, this must
+ * be called at application startup, prior to any calls to
+ * Calendar::createInstance to avoid undefined behavior.
+ *
* @param toAdopt the factory instance to be adopted
* @param status the in/out status code, no special meanings are assigned
* @return a registry key that can be used to unregister this factory
* register call. Key becomes invalid after a successful call and should not be used again.
* The CalendarFactory corresponding to the key will be deleted.
* INTERNAL in 2.6
+ *
+ * Because ICU may choose to cache Calendars internally, this should
+ * be called during application shutdown, after all calls to
+ * Calendar::createInstance to avoid undefined behavior.
+ *
* @param key the registry key returned by a previous call to registerFactory
* @param status the in/out status code, no special meanings are assigned
* @return TRUE if the factory for the key was successfully unregistered
#endif /* !UCONFIG_NO_SERVICE */
/**
- * @internal
* @return TRUE if this calendar has a default century (i.e. 03 -> 2003)
+ * @internal
*/
virtual UBool haveDefaultCentury() const = 0;
/**
- * @internal
* @return the start of the default century, as a UDate
+ * @internal
*/
virtual UDate defaultCenturyStart() const = 0;
/**
- * @internal
* @return the beginning year of the default century, as a year
+ * @internal
*/
virtual int32_t defaultCenturyStartYear() const = 0;
*/
Locale getLocale(ULocDataLocaleType type, UErrorCode &status) const;
+ /**
+ * @return The related Gregorian year; will be obtained by modifying the value
+ * obtained by get from UCAL_EXTENDED_YEAR field
+ * @internal
+ */
+ virtual int32_t getRelatedYear(UErrorCode &status) const;
+
+ /**
+ * @param year The related Gregorian year to set; will be modified as necessary then
+ * set in UCAL_EXTENDED_YEAR field
+ * @internal
+ */
+ virtual void setRelatedYear(int32_t year);
+
#ifndef U_HIDE_INTERNAL_API
/** Get the locale for this calendar object. You can choose between valid and actual locale.
* @param type type of the locale we're looking for (valid or actual)
* is not an instance of BasicTimeZone.
*/
BasicTimeZone* getBasicTimeZone() const;
+
+ /**
+ * Find the previous zone transtion near the given time.
+ * @param base The base time, inclusive
+ * @param transitionTime Receives the result time
+ * @param status The error status
+ * @return TRUE if a transition is found.
+ */
+ UBool getImmediatePreviousZoneTransition(UDate base, UDate *transitionTime, UErrorCode& status) const;
+
+public:
+#ifndef U_HIDE_INTERNAL_API
+ /**
+ * Creates a new Calendar from a Locale for the cache.
+ * This method does not set the time or timezone in returned calendar.
+ * @param locale the locale.
+ * @param status any error returned here.
+ * @return the new Calendar object with no time or timezone set.
+ * @internal For ICU use only.
+ */
+ static Calendar * U_EXPORT2 makeInstance(
+ const Locale &locale, UErrorCode &status);
+
+ /**
+ * Get the calendar type for given locale.
+ * @param locale the locale
+ * @param typeBuffer calendar type returned here
+ * @param typeBufferSize The size of typeBuffer in bytes. If the type
+ * can't fit in the buffer, this method sets status to
+ * U_BUFFER_OVERFLOW_ERROR
+ * @param status error, if any, returned here.
+ * @internal For ICU use only.
+ */
+ static void U_EXPORT2 getCalendarTypeFromLocale(
+ const Locale &locale,
+ char *typeBuffer,
+ int32_t typeBufferSize,
+ UErrorCode &status);
+#endif /* U_HIDE_INTERNAL_API */
};
// -------------------------------------
{
roll((UCalendarDateFields) field, up, status);
}
-#endif
+#endif /* U_HIDE_DEPRECATED_API */
// -------------------------------------
{
return weekNumber(dayOfPeriod, dayOfPeriod, dayOfWeek);
}
-#endif
+#endif /* U_HIDE_INTERNAL_API */
U_NAMESPACE_END
+#endif // U_SHOW_CPLUSPLUS_API
#endif /* #if !UCONFIG_NO_FORMATTING */
projects / apple / icu.git / blobdiff