Класс ThaiBuddhistChronology

Идентификатор уникально определяет Chronology. Он может быть использован для поиска Chronology с помощью Chronology.of(String).

Тип календаря — это идентификатор, определённый спецификацией Unicode Locale Data Markup Language (LDML). Он может быть использован для поиска Chronology с помощью Chronology.of(String). Он также может быть использован в качестве части локали, доступной через Locale.getUnicodeLocaleType(String) с ключом 'ca'.

Эта функция обращается к system clock в часовом поясе по умолчанию для получения текущей даты.

Использование этого метода предотвращает возможность использования альтернативных часов для тестирования, так как часы заданы жёстко.

Эта функция обращается к system clock для получения текущей даты. Указание часового пояса предотвращает зависимость от часового пояса по умолчанию.

Использование этого метода предотвращает возможность использования альтернативных часов для тестирования, так как часы заданы жёстко.

Эта функция обращается к указанным часам для получения текущей даты — сегодня. Использование этого метода позволяет использовать альтернативные часы для тестирования. Альтернативные часы могут быть введены с помощью dependency injection.

Это получает дату в этой хронологии на основе указанного временного объекта. TemporalAccessor представляет произвольный набор информации о дате и времени, которую этот фабричный метод преобразует в экземпляр ChronoLocalDate.

Преобразование обычно использует поле EPOCH_DAY, которое стандартизировано для всех систем календарей.

Этот метод соответствует сигнатуре функционального интерфейса TemporalQuery, что позволяет использовать его в качестве запроса через ссылку на метод, aChronology::date.

Это получает время и дату в этой хронологии на основе указанного временного объекта. TemporalAccessor представляет произвольный набор информации о дате и времени, которую этот фабричный метод преобразует в экземпляр ChronoLocalDateTime.

Преобразование извлекает и объединяет ChronoLocalDate и LocalTime из временного объекта. Реализации могут использовать оптимизации, такие как доступ к полям, эквивалентным соответствующим объектам. Результат использует эту хронологию.

Этот метод соответствует сигнатуре функционального интерфейса TemporalQuery, что позволяет использовать его в качестве запроса через ссылку на метод, aChronology::localDateTime.

Это получает зонированную дату и время в этой хронологии на основе указанного временного объекта. TemporalAccessor представляет собой произвольный набор информации о дате и времени, который эта фабрика преобразует в экземпляр ChronoZonedDateTime.

Преобразование сначала получит ZoneId из временного объекта, переходя к ZoneOffset при необходимости. Затем оно попытается получить Instant, переходя к ChronoLocalDateTime при необходимости. Результат будет либо комбинацией ZoneId или ZoneOffset с Instant или ChronoLocalDateTime. Реализации разрешается выполнять оптимизации, такие как доступ к тем полям, которые эквивалентны соответствующим объектам. Результат использует эту хронологию.

Этот метод соответствует подписи функционального интерфейса TemporalQuery, позволяя использовать его в качестве запроса через ссылку на метод, aChronology::zonedDateTime.

Это получает зонированную дату и время с тем же мгновением, что и указанное.

Високосные годы по буддистскому календарю соответствуют високосным годам ISO. Этот метод не проверяет переданный год и определяет результат только для годов в поддерживаемом диапазоне.

Это объединяет эру и год эры в одно поле пролептического года.

Если хронология активно использует эры, такие как JapaneseChronology, то год эры будет проверен относительно эры. Для других хронологий валидация является необязательной.

Эра, концептуально, — крупнейшая единица временной шкалы. Большинство систем календарей имеют одну эпоху, разделяющую временную шкалу на две эры. Однако некоторые имеют несколько эр, например, по одному на правление каждого лидера. Точное значение определяется хронологией в соответствии со следующими ограничениями.

Эра, используемая в 1970-01-01, должна иметь значение 1. Более поздние эры должны иметь последовательно большие значения. Более ранние эры должны иметь последовательно меньшие значения. Каждая хронология должна ссылаться на перечисление или аналогичный синглтон для предоставления значений эры.

Этот метод возвращает синглтон эры правильного типа для указанного значения эры.

Большинство систем календарей имеют эру, в которой год имеет смысл. Если система календаря не поддерживает концепцию эр, должен быть возвращен пустой список.

Все поля могут быть выражены как целое число long. Этот метод возвращает объект, описывающий допустимый диапазон для этого значения.

Обратите внимание, что результат описывает только минимальное и максимальное допустимые значения, и важно не делать слишком много выводов из них. Например, могут быть значения в диапазоне, которые недопустимы для поля.

Этот метод вернет результат, поддерживает ли хронология поле или нет.

Большинство реализаций TemporalField разрешаются с помощью метода resolve на поле. В отличие от этого, класс ChronoField определяет поля, имеющие смысл только относительно хронологии. Таким образом, поля даты ChronoField разрешаются здесь в контексте конкретной хронологии.

Экземпляры ChronoField разрешаются этим методом, который может быть переопределён в подклассах.

• EPOCH_DAY - Если присутствует, он преобразуется в дату, и все остальные поля даты проверяются на соответствие дате.
• PROLEPTIC_MONTH - Если присутствует, то он разделяется на YEAR и MONTH_OF_YEAR. Если режим строгий или интеллектуальный, то поле валидируется.
• YEAR_OF_ERA и ERA - Если оба присутствуют, они объединяются для создания YEAR. В мягком режиме диапазон YEAR_OF_ERA не валидируется, в интеллектуальном и строгом режимах - валидируется. Диапазон ERA валидируется во всех трёх режимах. Если присутствует только YEAR_OF_ERA, а режим интеллектуальный или мягкий, предполагается последняя имеющаяся эра. В строгом режиме эра не предполагается, и YEAR_OF_ERA остаётся без изменений. Если присутствует только ERA, то оно остаётся без изменений.
• YEAR, MONTH_OF_YEAR и DAY_OF_MONTH - Если все три присутствуют, они объединяются для создания даты. Во всех трёх режимах валидируется YEAR. Если режим интеллектуальный или строгий, то месяц и день валидируются. Если режим мягкий, дата комбинируется таким образом, как при создании даты на первое число первого месяца в указанном году, затем добавляется разница в месяцах, затем разница в днях. Если режим интеллектуальный, а день месяца больше максимального для года-месяца, то день месяца корректируется до последнего дня месяца. Если режим строгий, то три поля должны образовывать корректную дату.
• YEAR и DAY_OF_YEAR - Если оба присутствуют, они объединяются для создания даты. Во всех трёх режимах валидируется YEAR. Если режим мягкий, то дата комбинируется таким образом, как при создании даты на первое число указанного года, затем добавляется разница в днях. Если режим интеллектуальный или строгий, то два поля должны образовывать корректную дату.
• YEAR, MONTH_OF_YEAR, ALIGNED_WEEK_OF_MONTH и ALIGNED_DAY_OF_WEEK_IN_MONTH - Если все четыре присутствуют, они объединяются для создания даты. Во всех трёх режимах валидируется YEAR. Если режим мягкий, то дата комбинируется так, как при создании даты на первое число первого месяца в заданном году, затем добавляется разница в месяцах, затем в неделям, затем в днях. Если режим интеллектуальный или строгий, то все четыре поля валидируются в пределах своих диапазонов. Затем дата комбинируется аналогично созданию даты на первое число заданного года и месяца, затем добавляется количество недель и дней, чтобы достичь их значений. Если режим строгий, дата дополнительно проверяется на то, что корректировка дня и недели не изменила месяц.
• YEAR, MONTH_OF_YEAR, ALIGNED_WEEK_OF_MONTH и DAY_OF_WEEK - Если все четыре присутствуют, они объединяются для создания даты. Подход такой же, как описано выше для года, месяца и недель в ALIGNED_DAY_OF_WEEK_IN_MONTH. День недели корректируется как следующий или тот же соответствующий день недели после обработки года, месяца и недель.
• YEAR, ALIGNED_WEEK_OF_YEAR и ALIGNED_DAY_OF_WEEK_IN_YEAR - Если все три присутствуют, они объединяются для создания даты. Во всех трёх режимах валидируется YEAR. Если режим мягкий, то дата комбинируется аналогично созданию даты на первое число указанного года, затем добавляется разница в неделях, затем в днях. Если режим интеллектуальный или строгий, то все три поля валидируются в пределах своих диапазонов. Затем дата комбинируется аналогично созданию даты на первое число заданного года, затем добавляется количество недель и дней, чтобы достичь их значений. Если режим строгий, дата дополнительно проверяется на то, что корректировка дня и недели не изменила год.
• YEAR, ALIGNED_WEEK_OF_YEAR и DAY_OF_WEEK - Если все три присутствуют, они объединяются для создания даты. Подход такой же, как описано выше для года и недель в ALIGNED_DAY_OF_WEEK_IN_YEAR. День недели корректируется как следующий или тот же соответствующий день недели после обработки года и недель.

Реализация по умолчанию подходит для большинства календарных систем. Если ChronoField.YEAR_OF_ERA обнаружен без ChronoField.ERA, используется последняя эра в Chronology.eras(). Реализация предполагает семидневную неделю, что первое число месяца имеет значение 1, первое число года имеет значение 1, и что первое число месяца и года всегда существует.