Refactor foundational temporal types to java.time

[CydeWeys]

• Migrates core classes (Clock, Sleeper, TransactionManager) and extensive domain models from Joda-Time to java.time.
• Restores original public API method names while substituting parameters/return values with java.time.Instant.
• Updates JAXB XJC bindings.xjb to natively generate java.time.Instant and java.time.LocalDate, eliminating toDateTime wrapper methods.
• Fixes XML serializers (DateAdapter) to robustly convert OffsetDateTime timezone strings to UTC.
• Cleans up redundant imports and Checkstyle failures across the codebase.

Remaining Joda-Time surface area to migrate in future tasks:

• Command-line parameters (e.g. DateTimeParameter, DateParameter, IntervalParameter) in google.registry.tools.params.
• EPP/RDAP flow testing infrastructure (EppTestCase, RdapActionBaseTestCase, FlowTestCase).
• Beam pipelines and Load Testing modules (Spec11PipelineTest, RdePipelineTest, RegistryJpaReadTest, EppClient).
• Utility bridges and converters (DateTimeUtils.toDateTime/toInstant, DateTimeConverter, UtcDateTimeAdapter).
• Remaining UI Console tests and Actions.

---

This change is 

[gbrodman]

@gbrodman reviewed 323 files and all commit messages, made 8 comments, and resolved 1 discussion.
Reviewable status: all files reviewed, 7 unresolved discussions (waiting on CydeWeys).

---

core/src/test/java/google/registry/model/common/FeatureFlagTest.java line 86 at r3 (raw file):

                    ImmutableSortedMap.<Instant, FeatureStatus>naturalOrder()
                        .put(START_INSTANT, INACTIVE)
                        .put(fakeClock.now().plus(Duration.ofDays(56)), ACTIVE)

i've noticed a few times in this PR it changed intervals like this, (or like, 1 month to 31 days) -- do you know why it's doing this? it isn't really changing the test, just kinda odd

---

core/src/test/java/google/registry/flows/ResourceFlowTestCase.java line 87 at r3 (raw file):

    return refreshedResource;
  }

nit, extra newline

---

core/src/test/java/google/registry/flows/host/HostUpdateFlowTest.java line 195 at r3 (raw file):

    assertThat(ForeignKeyUtils.loadKey(Host.class, oldHostName(), clock.now())).isEmpty();
  }

nit, extra newline

---

core/src/test/java/google/registry/flows/poll/PollRequestFlowTest.java line 220 at r3 (raw file):

    runFlowAssertResponse(loadFile("poll_response_host_delete.xml"));
  }

nit newline

---

core/src/main/java/google/registry/flows/domain/DomainRenewFlow.java line 337 at r3 (raw file):

    if (!command
        .getCurrentExpirationDate()
        .equals(existingDomain.getRegistrationExpirationTime().atZone(UTC).toLocalDate())) {

i think we can also use the DateTimeUtils method here. Maybe worth grepping the codebase

---

core/src/main/java/google/registry/flows/certs/CertificateChecker.java line 99 at r3 (raw file):

  private static long getValidityLengthInDays(X509Certificate certificate) {
    return ChronoUnit.DAYS.between(
        certificate.getNotBefore().toInstant().atZone(UTC).toLocalDate(),

for these (and any other places where this is present in the codebase) we should use the DateTimeUtils method

---

config/presubmits.py line 223 at r2 (raw file):

        {},
    ):
        "Do not use toInstant(clock.now()). Use clock.now() instead.",

it seems silly to require these checks. Not wrong, just silly that we have to have these because of AI uncertainty

---

core/src/main/java/google/registry/persistence/converter/DurationUserType.java line 32 at r3 (raw file):

/**
 * Hibernate custom type for {@link java.time.Duration}.

nit: remove this change

[CydeWeys]

@CydeWeys made 2 comments.
Reviewable status: all files reviewed, 7 unresolved discussions (waiting on gbrodman).

---

config/presubmits.py line 223 at r2 (raw file):

Previously, gbrodman wrote…

it seems silly to require these checks. Not wrong, just silly that we have to have these because of AI uncertainty

Well this check at least will be gone shortly.

---

core/src/test/java/google/registry/model/common/FeatureFlagTest.java line 86 at r3 (raw file):

Previously, gbrodman wrote…

i've noticed a few times in this PR it changed intervals like this, (or like, 1 month to 31 days) -- do you know why it's doing this? it isn't really changing the test, just kinda odd

The java.time.Duration API does not have an ofWeeks() method. The largest unit it has is days, which is consistent with the overall idea that anything larger than that is indeterminate (is a month 28, 29, 30, or 31 days? Is a year 365 or 366 days? Etc.).

[CydeWeys]

@CydeWeys made 2 comments and resolved 4 discussions.
Reviewable status: 315 of 324 files reviewed, 3 unresolved discussions (waiting on gbrodman).

---

core/src/main/java/google/registry/flows/certs/CertificateChecker.java line 99 at r3 (raw file):

Previously, gbrodman wrote…

for these (and any other places where this is present in the codebase) we should use the DateTimeUtils method

Done.

---

core/src/main/java/google/registry/flows/domain/DomainRenewFlow.java line 337 at r3 (raw file):

Previously, gbrodman wrote…

i think we can also use the DateTimeUtils method here. Maybe worth grepping the codebase

Done.

[CydeWeys]

PTAL

@CydeWeys made 1 comment.
Reviewable status: 315 of 324 files reviewed, 3 unresolved discussions (waiting on gbrodman).

[gbrodman]

@gbrodman reviewed 9 files and all commit messages, and resolved 3 discussions.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on CydeWeys).