Replace ZonedDateTime with Instant

[david-livefront]

🎟️ Tracking

N/A

📔 Objective

This PR replaces the usage of ZonedDateTime with Instant. All the dates in the app are in UTC already and the Bitwarden SDK uses Instant as well. This should simplify logic within the app and remove the need to convert class types when interacting with the SDK.

[david-livefront]

The schema does not need to be updated because we have a TypeConvertor that is transforming the value to a Long. So the stored datatype has not actually changed.

[claude]

Claude finished @david-livefront's task in 4m 20s —— View job

---

Pull Request Review: Replace ZonedDateTime with Instant

Summary

This PR replaces ZonedDateTime with Instant across the entire codebase (112 files, +566/-680 lines). The migration is well-motivated: all dates are already in UTC, the Bitwarden SDK uses Instant, and removing the unnecessary timezone wrapping simplifies the code and eliminates conversion overhead.

The migration is clean and mechanically correct. Key areas verified:

• Serialization compatibility: InstantSerializer preserves the same ISO 8601 format. Deserialization still parses through ZonedDateTime.parse().toInstant() for robust timezone handling. The addition of .withZone(ZoneOffset.UTC) on the serialization formatter is correct since Instant does not carry zone info.
• Database compatibility: The InstantTypeConverter stores/retrieves the same Long (epoch seconds) as the old ZonedDateTimeTypeConverter, so no schema migration is needed.
• Binary long conversion: getInstantFromBinaryLong/getBinaryLongFromInstant correctly replicate their ZonedDateTime predecessors with round-trip correctness verified by tests.
• SDK-to-network conversions: All ZonedDateTime.ofInstant()/.toInstant() adapter code is correctly removed now that both sides use Instant.
• Azure Blob Storage date header: RFC_1123_DATE_TIME.withZone(ZoneOffset.UTC).format(clock.instant()) is semantically equivalent to the previous ZonedDateTime approach.
• Parcelize compatibility: Instant implements java.io.Serializable, so @Parcelize state classes with Instant fields work correctly.
• No stale ZonedDateTime usage: Only two remaining references -- InstantSerializer.kt (intentional, for robust deserialization) and LegacySecureStorageImpl.kt (out of scope, used for Android Keystore certificate generation).
• Test coverage: Comprehensive -- serializer, type converter, binary long utils, and all consuming ViewModel/Repository/Manager tests are updated.

Findings

No issues found. The migration is consistent and correct across all changed files.

---

Re-reviewed after rebase onto latest main. No substantive code changes from the previous review.

[david-livefront]

Little conversions like this are just not needed anymore.

[github-actions]

Checkmarx One – Scan Summary & Details – 7af56545-6cfd-4ff1-ac26-b5e8000e504e

Great job! No new security vulnerabilities introduced in this pull request

[david-livefront]

This is one of the few remaining places that still uses the ZonedDateTime.

I did test out using Instant.parse(decoder.decodeString()) and did not see any negative ramification of the change but I am unsure of a good way to validate that it works for any and all variations the server could send back to us.

So for the moment, I have left it as a ZonedDateTime, which we know works, and then convert it to an Instant.

[david-livefront]

Any concerns with migrating directly to Instant with this:

override fun deserialize(decoder: Decoder): Instant = Instant.parse(decoder.decodeString())

[SaintPatrck]

I like that ZonedDateTime is more permissive. I'm assuming the DateTimeFormatter pattern accepts . or : as a separator for a reason, and if : is received, Instant.parse() is going to fail. ZonedDateTime also handles various timezone offset formats more gracefully.

If we're not able to guarantee the server's format now and in the future, ZonedDateTime feels like the safer approach. The flexibility is worth the couple of extra lines, imo.

[david-livefront]

Fair enough, we will run with this for now.

[codecov]

Codecov Report

❌ Patch coverage is 92.42424% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.41%. Comparing base (d1cf808) to head (13b18e8).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
...addedit/components/AddEditSendCustomDateChooser.kt	33.33%	2 Missing ⚠️
...bitwarden/data/platform/manager/PushManagerImpl.kt	50.00%	0 Missing and 1 partial ⚠️
...dedit/components/AddEditSendDeletionDateChooser.kt	0.00%	1 Missing ⚠️
...otlin/com/bitwarden/core/util/InstantExtensions.kt	75.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6554      +/-   ##
==========================================
- Coverage   86.45%   86.41%   -0.04%     
==========================================
  Files         786      802      +16     
  Lines       56712    57144     +432     
  Branches     8258     8255       -3     
==========================================
+ Hits        49028    49380     +352     
- Misses       4817     4904      +87     
+ Partials     2867     2860       -7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[SaintPatrck]

LGTM!

[david-livefront]

Thanks @SaintPatrck