JV Java · 25 вопросов · ~70 мин · ⏱ Таймер 10:00 · Средний ·

Дата, время и часовые пояса

Разбирает тему «Дата, время и часовые пояса» на практических сценариях: поиск дефектов, сравнение решений и оценка последствий. Вопросы перемешаны: встречаются трассировка, ошибка компиляции, выбор правки, граничный сценарий и оценка инженерного компромисса. Базовая версия — Java 25 LTS; если версия не названа отдельно, используются устойчивые правила, совместимые с Java 21.

Отвечено: 0 из 25

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 25 вопросов отведено 70 минут. В каждом вопросе верен только один вариант; близкие ответы различаются стадией ошибки, порядком действий или границей контракта. После завершения вы увидите общий результат, результаты по 5 тематическим шкалам и объяснения.

Вопрос 1 из 25

Какой граничный случай особенно важен для темы «Тестирование и диагностика» в разделе «Дата, время и часовые пояса»?

class ExpiryService {
    boolean expired(java.time.Instant deadline) {
        return java.time.Instant.now().isAfter(deadline);
    }
}

Правила tzdb могут обновляться между версиями JDK, меняя будущие преобразования для некоторых регионов. Instant не содержит исходную временную зону или намерение локального расписания. MM — месяц, mm — минуты; регистр букв шаблона меняет смысл. Фиксированный Clock не проверяет движение времени; для этого нужны управляемые часы или заранее заданная последовательность значений. Во время перехода на летнее время локальное время может отсутствовать или встречаться дважды.

Вопрос 2 из 25

Какое правило Java действует для темы «Форматирование» в разделе «Дата, время и часовые пояса»?

ZoneId хранит региональные правила с историей переходов, а фиксированный ZoneOffset — только смещение. Instant представляет точку UTC с секундной и наносекундной точностью, не календарное представление пользователя. Тесты времени должны управлять Clock, зоной и локалью, а также покрывать переходы DST и границы периода. DateTimeFormatter неизменяем и потокобезопасен; шаблон должен соответствовать типу и локали. LocalDateTime хранит локальные поля даты и времени без часового пояса и не определяет однозначный момент на временной шкале.

Вопрос 3 из 25

Как точнее оценить пользу и цену решения по теме «Локальные дата и время» в разделе «Дата, время и часовые пояса»?

Удаление общего состояния часто лучше блокировки, но копирование и объединение могут увеличить память и задержку. LocalDateTime удобен для «каждый день в 10:00», но опасен для журналов событий и межсистемных отметок. LocalDateTime удобен для «каждый день в 9:00», но опасен для журналов событий и межсистемных отметок. Крупная критическая секция проще для корректности, но снижает параллелизм и увеличивает задержку ожидания. LocalDateTime удобен для «каждый день в 8:00», но опасен для журналов событий и межсистемных отметок.

Вопрос 4 из 25

Что следует изменить в разделе «Дата, время и часовые пояса», чтобы сохранить замысел и соблюсти контракт «Тестирование и диагностика»?

// Фрагмент на ревью
class ExpiryService {
    boolean expired(java.time.Instant deadline) {
        return java.time.Instant.now().isAfter(deadline);
    }
}

Хранить технические временные отметки как Instant и форматировать в пользовательской ZoneId на границе. Передать Clock и вызывать LocalDate.now(clock) или Instant.now(clock). Сохранять ZoneId пользователя для расписаний, а не вычисленное однажды смещение. Для календарной даты использовать uuuu-MM-dd или yyyy с осознанной эрой, а не YYYY. Передать Clock и вызывать LocalDate.now(clock) или LocalDateTime.now(clock).

Вопрос 5 из 25

Какое замечание о сопровождении или производительности темы «Тестирование и диагностика» в разделе «Дата, время и часовые пояса» справедливо?

LocalDateTime удобен для «каждый день в 9:00», но опасен для журналов событий и межсистемных отметок. Региональная зона точнее отражает намерение, но требует версии правил и аккуратной обработки неоднозначных локальных времён. Детерминированные часы упрощают тесты, но интеграция всё равно должна проверить системную зону и сериализацию. Строгий форматировщик ловит недопустимые даты, но пользовательские названия месяцев требуют подходящей Locale. Единая шкала времени упрощает интеграцию, но для календарных правил нужны ZonedDateTime и правила зоны.

Вопрос 6 из 25

Какая правка точнее всего устраняет причину проблемы по теме «Моменты времени Instant» в разделе «Дата, время и часовые пояса»?

// Фрагмент на ревью
var a = java.time.OffsetDateTime.parse("2026-07-14T10:00+03:00").toInstant();
var b = java.time.OffsetDateTime.parse("2026-07-14T07:00Z").toInstant();
System.out.println(a.equals(b));

Хранить технические временные отметки как LocalDateTime и форматировать в пользовательской ZoneId на границе. Передавать StandardCharsets.UTF_8 или другую кодировку, заданную контрактом формата, на границе чтения и записи. Хранить бизнес-локальное время вместе с ZoneId либо преобразовывать момент в Instant. Хранить технические временные отметки как Instant и форматировать в пользовательской ZoneOffset на границе. Хранить технические временные отметки как Instant и форматировать в пользовательской ZoneId на границе.

Вопрос 7 из 25

Почему шаблон YYYY-MM-dd может дать неожиданный год для даты 1 января?

var d = java.time.LocalDate.of(2021, 1, 1);
var f = java.time.format.DateTimeFormatter
    .ofPattern("YYYY-MM-dd", java.util.Locale.GERMANY);
System.out.println(f.format(d));

Locale влияет только на названия месяцев и не может влиять на недельный год. YYYY — год недели; здесь дата относится к последней неделе 2020 года, поэтому вывод будет 2020-01-01. YYYY и yyyy полностью взаимозаменяемы, поэтому вывод всегда 2021-01-01. LocalDate нельзя форматировать шаблоном с годом недели. MM обозначает минуты, поэтому код завершится DateTimeException.

Вопрос 8 из 25

Какая правка точнее всего устраняет причину проблемы по теме «Локальные дата и время» в разделе «Дата, время и часовые пояса»?

// Фрагмент на ревью
var local = java.time.LocalDateTime.of(2026, 7, 14, 10, 0);
var tallinn = local.atZone(java.time.ZoneId.of("Europe/Tallinn")).toInstant();
var tokyo = local.atZone(java.time.ZoneId.of("Asia/Tokyo")).toInstant();
System.out.println(tallinn.equals(tokyo));

Хранить бизнес-локальное время вместе с ZoneId либо преобразовывать момент в LocalDateTime. Сохранять ZoneId пользователя для расписаний, а не вычисленное однажды смещение. Хранить бизнес-локальное время вместе с ZoneId либо преобразовывать момент в Instant. Хранить бизнес-локальное время вместе с ZoneOffset либо преобразовывать момент в Instant. Хранить технические временные отметки как Instant и форматировать в пользовательской ZoneId на границе.

Вопрос 9 из 25

Какая правка точнее всего устраняет причину проблемы по теме «Форматирование» в разделе «Дата, время и часовые пояса»?

// Фрагмент на ревью
var d = java.time.LocalDate.of(2021, 1, 1);
var f = java.time.format.DateTimeFormatter.ofPattern("YYYY-MM-dd");
System.out.println(f.format(d));

Хранить бизнес-локальное время вместе с ZoneId либо преобразовывать момент в Instant. Хранить технические временные отметки как Instant и форматировать в пользовательской ZoneId на границе. Сохранять ZoneId пользователя для расписаний, а не вычисленное однажды смещение. Настроить ThreadPoolExecutor с ограниченной очередью, политикой отклонения и метриками. Для календарной даты использовать uuuu-MM-dd или yyyy с осознанной эрой, а не YYYY.

Вопрос 10 из 25

Какое ограничение механизма «Моменты времени Instant» нельзя упускать при работе с разделом «Дата, время и часовые пояса»?

// Минимальный пример
var a = java.time.OffsetDateTime.parse("2026-07-14T10:00+03:00").toInstant();
var b = java.time.OffsetDateTime.parse("2026-07-14T07:00Z").toInstant();
System.out.println(a.equals(b));

Двойная буферизация обычно не добавляет пользы и может усложнить контроль задержки. Instant не содержит исходную временную зону или намерение локального расписания. Files.exists подвержен гонке TOCTOU; операция после проверки всё равно может завершиться ошибкой. LocalDateTime не содержит исходную временную зону или намерение локального расписания. synchronized static использует монитор Class-объекта и не совпадает с монитором экземпляра.

Вопрос 11 из 25

Что нужно отдельно проверить на границе контракта «Локальные дата и время» в разделе «Дата, время и часовые пояса»?

Один объект Thread нельзя запустить второй раз; повторный start даёт IllegalThreadStateException. Files.exists подвержен гонке TOCTOU; операция после проверки всё равно может завершиться ошибкой. Во время перехода на летнее время локальное время может отсутствовать или встречаться дважды. MM — месяц, mm — минуты; регистр букв шаблона меняет смысл. Тип char хранит одну кодовую единицу UTF-16; один пользовательский знак может занимать две такие единицы.

Вопрос 12 из 25

Что произойдёт с кодом по теме «Форматирование» в разделе «Дата, время и часовые пояса»?

var d = java.time.LocalDate.of(2021, 1, 1);
var f = java.time.format.DateTimeFormatter.ofPattern("YYYY-MM-dd");
System.out.println(f.format(d));

Шаблон YYYY обозначает год по неделям ISO, поэтому около Нового года может отличаться от календарного yyyy. Одинаковое локальное время 10:00 в Таллине и Токио обозначает разные моменты, поэтому сравнение двух Instant печатает false. Сравнение Instant корректно упорядочивает события, записанные из разных зон. Europe/Tallinn и +03:00 совпадают летом, но региональная зона знает будущие и зимние изменения. Instant.now() внутри метода делает проверку недетерминированной: результат может измениться прямо на границе крайнего срока между подготовкой данных и вызовом.

Вопрос 13 из 25

На какое правило следует опираться при разборе темы «Локальные дата и время» в разделе «Дата, время и часовые пояса»?

Instant хранит локальные поля даты и времени без часового пояса и не определяет однозначный момент на временной шкале. Reader и Writer преобразуют байты и символы через выбранную кодировку; кодировка внешнего формата должна быть указана явно. DateTimeFormatter неизменяем и потокобезопасен; шаблон должен соответствовать типу и локали. Без happens-before поток может не увидеть изменение обычного поля; volatile даёт видимость и порядок, но не атомарность составной операции. LocalDateTime хранит локальные поля даты и времени без часового пояса и не определяет однозначный момент на временной шкале.

Вопрос 14 из 25

Что следует изменить в разделе «Дата, время и часовые пояса», чтобы сохранить замысел и соблюсти контракт «Часовые зоны ZoneId»?

// Фрагмент на ревью
var zone = java.time.ZoneId.of("Europe/Tallinn");
var winter = java.time.LocalDate.of(2026,1,15).atStartOfDay(zone);
var summer = java.time.LocalDate.of(2026,7,15).atStartOfDay(zone);
System.out.println(winter.getOffset() + ":" + summer.getOffset());

Хранить технические временные отметки как Instant и форматировать в пользовательской ZoneId на границе. Синхронизироваться на общем объекте, который действительно защищает общее состояние. Хранить бизнес-локальное время вместе с ZoneId либо преобразовывать момент в Instant. Сохранять ZoneId пользователя для расписаний, а не вычисленное однажды смещение. Сохранять ZoneOffset пользователя для расписаний, а не вычисленное однажды смещение.

Вопрос 15 из 25

Какое утверждение о механизме «Часовые зоны ZoneId» верно в контексте раздела «Дата, время и часовые пояса»?

ZoneId хранит региональные правила с историей переходов, а фиксированный ZoneOffset — только смещение. ZoneId хранит региональные правила с историей переходов, а фиксированный ZoneId — только смещение. ZoneOffset хранит региональные правила с историей переходов, а фиксированный ZoneOffset — только смещение. Path представляет путь без обязательного существования файла, а Files выполняет операции файловой системы. Гонка возникает, когда результат зависит от неконтролируемого порядка конкурентных доступов к общему изменяемому состоянию.

Вопрос 16 из 25

Какое замечание о сопровождении или производительности темы «Моменты времени Instant» в разделе «Дата, время и часовые пояса» справедливо?

Единая шкала времени упрощает интеграцию, но для календарных правил нужны ZonedDateTime и правила зоны. Детерминированные часы упрощают тесты, но интеграция всё равно должна проверить системную зону и сериализацию. NIO.2 даёт удобные атомарные и метаданные операции, но безопасность пути нельзя строить на одной строковой проверке. Тесты в памяти быстры, а интеграционные проверки файловой системы нужны для прав, атомарных перемещений и платформенных различий. Крупная критическая секция проще для корректности, но снижает параллелизм и увеличивает задержку ожидания.

Вопрос 17 из 25

Какой контракт языка или библиотеки точнее всего описывает тему «Моменты времени Instant» в разделе «Дата, время и часовые пояса»?

DateTimeFormatter неизменяем и потокобезопасен; шаблон должен соответствовать типу и локали. Instant представляет точку UTC с секундной и наносекундной точностью, не календарное представление пользователя. Path представляет путь без обязательного существования файла, а Files выполняет операции файловой системы. LocalDateTime представляет точку UTC с секундной и наносекундной точностью, не календарное представление пользователя. Reader и Writer преобразуют байты и символы через выбранную кодировку; кодировка внешнего формата должна быть указана явно.

Вопрос 18 из 25

Какое правило Java действует для темы «Тестирование и диагностика» в разделе «Дата, время и часовые пояса»?

Instant представляет точку UTC с секундной и наносекундной точностью, не календарное представление пользователя. Тесты времени должны управлять Clock, зоной и локалью, а также покрывать переходы DST и границы периода. ZoneId хранит региональные правила с историей переходов, а фиксированный ZoneOffset — только смещение. Path представляет путь без обязательного существования файла, а Files выполняет операции файловой системы. LocalDateTime хранит локальные поля даты и времени без часового пояса и не определяет однозначный момент на временной шкале.

Вопрос 19 из 25

Что важно учитывать при применении механизма «Форматирование» из раздела «Дата, время и часовые пояса» в рабочем проекте?

Детерминированные часы упрощают тесты, но интеграция всё равно должна проверить системную зону и сериализацию. LocalDateTime удобен для «каждый день в 9:00», но опасен для журналов событий и межсистемных отметок. Удаление общего состояния часто лучше блокировки, но копирование и объединение могут увеличить память и задержку. Единая шкала времени упрощает интеграцию, но для календарных правил нужны ZonedDateTime и правила зоны. Строгий форматировщик ловит недопустимые даты, но пользовательские названия месяцев требуют подходящей Locale.

Вопрос 20 из 25

Что произойдёт с кодом по теме «Моменты времени Instant» в разделе «Дата, время и часовые пояса»?

var a = java.time.OffsetDateTime.parse("2026-07-14T10:00+03:00").toInstant();
var b = java.time.OffsetDateTime.parse("2026-07-14T07:00Z").toInstant();
System.out.println(a.equals(b));

Запись в BufferedWriter может не попасть в файл до flush или close. Сравнение LocalDateTime корректно упорядочивает события, записанные из разных зон. Шаблон YYYY обозначает год по неделям ISO, поэтому около Нового года может отличаться от календарного yyyy. Одинаковое локальное время 10:00 в Таллине и Токио обозначает разные моменты, поэтому сравнение двух Instant печатает false. Сравнение Instant корректно упорядочивает события, записанные из разных зон.

Вопрос 21 из 25

Почему такой метод трудно проверять воспроизводимым тестом на границе срока?

class ExpiryService {
    boolean expired(java.time.Instant deadline) {
        return java.time.Instant.now().isAfter(deadline);
    }
}

Instant.now() внутри метода делает проверку недетерминированной: результат может измениться прямо на границе крайнего срока между подготовкой данных и вызовом. Тест с ForkJoinPool.commonPool() может зависнуть или давать нестабильный результат из-за чужой нагрузки в той же JVM. LocalDateTime.now() внутри метода делает проверку недетерминированной: результат может измениться прямо на границе крайнего срока между подготовкой данных и вызовом. Europe/Tallinn и +03:00 совпадают летом, но региональная зона знает будущие и зимние изменения. Одинаковое локальное время 10:00 в Таллине и Токио обозначает разные моменты, поэтому сравнение двух Instant печатает false.

Вопрос 22 из 25

В каком дополнительном сценарии вывод о теме «Часовые зоны ZoneId» в разделе «Дата, время и часовые пояса» может оказаться неверным?

// Минимальный пример
var zone = java.time.ZoneId.of("Europe/Tallinn");
var winter = java.time.LocalDate.of(2026,1,15).atStartOfDay(zone);
var summer = java.time.LocalDate.of(2026,7,15).atStartOfDay(zone);
System.out.println(winter.getOffset() + ":" + summer.getOffset());

Правила tzdb могут обновляться между версиями JDK, меняя будущие преобразования для некоторых регионов. synchronized static использует монитор Class-объекта и не совпадает с монитором экземпляра. volatile count++ всё ещё теряет обновления, поскольку чтение, сложение и запись — отдельные действия. MM — месяц, mm — минуты; регистр букв шаблона меняет смысл. Тип char хранит одну кодовую единицу UTF-16; один пользовательский знак может занимать две такие единицы.

Вопрос 23 из 25

Каков точный результат выполнения или компиляции фрагмента из раздела «Дата, время и часовые пояса» по теме «Часовые зоны ZoneId»?

var zone = java.time.ZoneId.of("Europe/Tallinn");
var winter = java.time.LocalDate.of(2026,1,15).atStartOfDay(zone);
var summer = java.time.LocalDate.of(2026,7,15).atStartOfDay(zone);
System.out.println(winter.getOffset() + ":" + summer.getOffset());

Europe/Tallinn и +4:00 совпадают летом, но региональная зона знает будущие и зимние изменения. Europe/Tallinn и +2:00 совпадают летом, но региональная зона знает будущие и зимние изменения. Два потока могут прочитать одно value и записать одинаковый увеличенный результат, потеряв одно обновление. Europe/Tallinn и +03:00 совпадают летом, но региональная зона знает будущие и зимние изменения. Одинаковое локальное время 10:00 в Таллине и Токио обозначает разные моменты, поэтому сравнение двух Instant печатает false.

Вопрос 24 из 25

Что важно учитывать при применении механизма «Часовые зоны ZoneId» из раздела «Дата, время и часовые пояса» в рабочем проекте?

Региональная зона точнее отражает намерение, но требует версии правил и аккуратной обработки неоднозначных локальных времён. Детерминированные часы упрощают тесты, но интеграция всё равно должна проверить системную зону и сериализацию. Удаление общего состояния часто лучше блокировки, но копирование и объединение могут увеличить память и задержку. Явная кодировка делает обмен воспроизводимым, но для внешнего формата всё равно надо определить правила BOM и обработки ошибочных последовательностей. Региональная зона точнее отражает намерение, но не требует версии правил и аккуратной обработки неоднозначных локальных времён.

Вопрос 25 из 25

Что произойдёт с кодом по теме «Локальные дата и время» в разделе «Дата, время и часовые пояса»?

var local = java.time.LocalDateTime.of(2026, 7, 14, 10, 0);
var tallinn = local.atZone(java.time.ZoneId.of("Europe/Tallinn")).toInstant();
var tokyo = local.atZone(java.time.ZoneId.of("Asia/Tokyo")).toInstant();
System.out.println(tallinn.equals(tokyo));

Одинаковое локальное время 10:00 в Таллине и Токио обозначает разные моменты, поэтому сравнение двух Instant печатает false. Одинаковое локальное время 9:00 в Таллине и Токио обозначает разные моменты, поэтому сравнение двух Instant печатает false. Сравнение Instant корректно упорядочивает события, записанные из разных зон. Одинаковое локальное время 11:00 в Таллине и Токио обозначает разные моменты, поэтому сравнение двух Instant печатает false. Шаблон YYYY обозначает год по неделям ISO, поэтому около Нового года может отличаться от календарного yyyy.

Ответьте на все 25 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу