Skip to content

Conversation

@sffc
Copy link
Member

@sffc sffc commented May 1, 2025

Mostly fixes #6378

It doesn't make FFI work for ZonedDateFormatter and ZonedTimeFormatter since this trick only works for ZonedDateTimeFormatter, but at least this is progress.

@sffc sffc requested review from a team, Manishearth and zbraniecki as code owners May 1, 2025 23:42
Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello @sffc, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

Summary of Changes

This pull request addresses issue #6378 by inferring the zone datetime in FFI when possible. The changes primarily involve modifying the DateTimeInputUnchecked struct and updating the FFI bindings for ZonedDateTimeFormatter to automatically set the time zone name timestamp when it's not explicitly provided. This enhancement improves FFI support, particularly for ZonedDateTimeFormatter, although it doesn't yet extend to ZonedDateFormatter and ZonedTimeFormatter.

Highlights

  • FFI Enhancement: The pull request enhances FFI support by enabling the inference of zone datetime when possible, specifically targeting ZonedDateTimeFormatter.
  • Automatic Time Zone Timestamp: The changes introduce automatic setting of the time zone name timestamp in ZonedDateTimeFormatter when it's not explicitly provided, using ZoneNameTimestamp::from_date_time_iso.
  • Code Modification: The code has been modified to use date_in_calendar instead of date in set_date_fields_unchecked for clarity and consistency.

Changelog

Click here to see the changelog
  • components/datetime/src/format/input.rs
    • Renamed input to date_in_calendar in set_date_fields_unchecked for better readability.
  • ffi/capi/src/zoned_date_formatter.rs
    • Renamed date to date_in_calendar in write_to_diplomat for better readability.
  • ffi/capi/src/zoned_date_time_formatter.rs
    • Renamed date to date_in_calendar in write_to_diplomat for better readability.
    • Added logic to automatically set time_zone_name_timestamp using ZoneNameTimestamp::from_date_time_iso when not explicitly provided.
  • ffi/dart/test/icu_test.dart
    • Added test case with customZDT and customZone to test the new functionality.
    • Changed ZonedDateTimeFormatter.genericLong to ZonedDateTimeFormatter.specificLong in one of the tests.
    • Added a new expectation to test ZonedDateTimeFormatter.genericLong with customZDT and customZone.
  • tools/make/codegen/templates/zoned_formatter.rs.jinja
    • Renamed date to date_in_calendar in the generated code for better readability.
    • Added logic to automatically set time_zone_name_timestamp using ZoneNameTimestamp::from_date_time_iso when not explicitly provided in the generated code.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in issue comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.


In zones of time, a dance,
FFI's grace, a hopeful chance.
DateTime's form,
Weathering the storm,
In code's embrace, we advance.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a change to infer the zone datetime in FFI when possible, which is a good step towards fixing #6378. The changes look reasonable, but there are a few areas that could be improved for clarity and correctness.

Summary of Findings

  • Naming consistency: The naming of variables could be more consistent across the codebase. For example, date_in_calendar is used in some places, while date is used in others. Standardizing this would improve readability.
  • Missing time zone name timestamp: The logic for setting the time zone name timestamp could be simplified and made more robust. Currently, it only sets the timestamp if it's explicitly provided, but it should also handle the case where it's not provided and can be inferred from the date and time.

Merge Readiness

The pull request makes progress towards resolving issue #6378, but it doesn't fully address the problem. There are also some areas for improvement in terms of naming consistency and logic simplification. I recommend addressing the high severity issue before merging. I am unable to approve this pull request, and users should have others review and approve this code before merging.

Comment on lines +531 to +536
else {
input.set_time_zone_name_timestamp(icu_time::zone::ZoneNameTimestamp::from_date_time_iso(&icu_time::DateTime {
date: date.0,
time: time.0
}))
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

This else block is intended to infer the time zone name timestamp when it's not explicitly provided. However, it's unconditionally setting the timestamp based on the date and time. This might not always be the desired behavior. It would be better to check if the timestamp can be inferred from the zone ID before setting it here. Otherwise, the code might be overwriting a valid timestamp with an inferred one.

Suggested change
else {
input.set_time_zone_name_timestamp(icu_time::zone::ZoneNameTimestamp::from_date_time_iso(&icu_time::DateTime {
date: date.0,
time: time.0
}))
}
if let Some(zone_name_timestamp) = zone.zone_name_timestamp {
input.set_time_zone_name_timestamp(zone_name_timestamp);
}
else if zone.id.is_some() {
input.set_time_zone_name_timestamp(icu_time::zone::ZoneNameTimestamp::from_date_time_iso(&icu_time::DateTime {
date: date.0,
time: time.0
}))
}

Comment on lines +1031 to +1036
else {
input.set_time_zone_name_timestamp(icu_time::zone::ZoneNameTimestamp::from_date_time_iso(&icu_time::DateTime {
date: date.0,
time: time.0
}))
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

This else block is intended to infer the time zone name timestamp when it's not explicitly provided. However, it's unconditionally setting the timestamp based on the date and time. This might not always be the desired behavior. It would be better to check if the timestamp can be inferred from the zone ID before setting it here. Otherwise, the code might be overwriting a valid timestamp with an inferred one.

Suggested change
else {
input.set_time_zone_name_timestamp(icu_time::zone::ZoneNameTimestamp::from_date_time_iso(&icu_time::DateTime {
date: date.0,
time: time.0
}))
}
if let Some(zone_name_timestamp) = zone.zone_name_timestamp {
input.set_time_zone_name_timestamp(zone_name_timestamp);
}
else if zone.id.is_some() {
input.set_time_zone_name_timestamp(icu_time::zone::ZoneNameTimestamp::from_date_time_iso(&icu_time::DateTime {
date: date.0,
time: time.0
}))
}

@sffc
Copy link
Member Author

sffc commented May 1, 2025

@gemini-code-assist What makes you think that the zone name timestamp can be inferred from the time zone ID

@sffc sffc removed request for Manishearth and zbraniecki May 1, 2025 23:47
@gemini-code-assist
Copy link

Hi @sffc,

Thanks for the question! My reasoning was based on the assumption that if the time zone ID is known, and the ZonedDateTimeFormatter is already working with a specific date and time, then it's possible to create a ZoneNameTimestamp from that date and time using ZoneNameTimestamp::from_date_time_iso. This function essentially captures the moment when the zone name was valid for that specific date and time.

However, you're right to point out that this inference might not always be accurate or desired. There could be scenarios where the user wants to explicitly provide a zone_name_timestamp that is different from the one inferred from the date and time. Also, it's not a true 'inference' since it's derived from the date and time, not the ID itself.

I hope this clarifies my thought process. I'm open to discussing alternative approaches or refinements to this logic!

@sffc
Copy link
Member Author

sffc commented May 1, 2025

But @gemini-code-assist, this PR is doing exactly what you asked for, I think. If the zone name timestamp was explicitly provided, we use it, and otherwise, we fall back to the formattable date and time.

@gemini-code-assist
Copy link

Hi @sffc,

You're absolutely right! Thanks for pointing that out. I was a bit too quick in my previous assessment. I appreciate you implementing the logic as intended, prioritizing the explicitly provided timestamp when available and falling back to the formattable date and time when it's not.

@sffc
Copy link
Member Author

sffc commented May 2, 2025

Ping @unicode-org/icu4x-owners

@Manishearth
Copy link
Member

(I did have this in my queue, I was just deep in V8 stuff)

@sffc sffc merged commit 2c0b3ef into unicode-org:main May 2, 2025
29 checks passed
@sffc sffc deleted the ffi-datetime-infer branch May 2, 2025 21:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ZonedDateTime FFI: How to set/infer the local time?

2 participants