Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Make timezone in "strict_date_time" format optional #16701

Closed
wants to merge 2 commits into from
Closed

Make timezone in "strict_date_time" format optional #16701

wants to merge 2 commits into from
+21 −0

Conversation

peteralfonsi
Copy link
Contributor

Description

Changes "strict_date_time" format to make the timezone optional. For example, 2024-06-01T13:38:18.280 was not previously allowed, only 2024-06-01T13:38:18.280Z or 2024-06-01T13:38:18.280Z+00:00. If there's no timezone, it defaults to UTC. This is useful as Python's isoformat() can output times like this, and they are ISO 8601 compliant.

Adds UT. Also tested manually with the mapping:

"timestamp":    { 
    "type" : "date", 
    "format":"strict_date_time" 
}

and indexing two documents, one with timestamp "2023-01-01T14:14:14Z" and one with "2023-01-01T14:14:14". In the existing code, the second one failed with RequestError(400, 'mapper_parsing_exception', "failed to parse field [timestamp] of type [date] in document with id '2'. Preview of field's value: '2023-02-02T14:14:14'").

After this change, both are accepted.

Related Issues

Resolves #16673

Check List

  • Functionality includes testing.
  • API changes companion pull request created, if applicable.
  • Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@github-actions github-actions bot added bug Something isn't working Search Search query, autocomplete ...etc labels Nov 22, 2024
Changelog
d54ff3c 
Signed-off-by: Peter Alfonsi <[email protected]>
@peteralfonsi peteralfonsi added the backport 2.x Backport to 2.x branch label Nov 22, 2024
reta
reta requested changes Nov 22, 2024
View reviewed changes
server/src/main/java/org/opensearch/common/time/DateFormatters.java
@@ -741,7 +743,9 @@ public class DateFormatters {
.toFormatter(Locale.ROOT)
.withResolverStyle(ResolverStyle.STRICT),
new DateTimeFormatterBuilder().append(STRICT_DATE_FORMATTER)
.optionalStart()
Copy link
Collaborator

Choose a reason for hiding this comment

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

One of the reasons it is called STRICT_DATE_TIME is because all components are required, changing that would lead to surprising results. We have a large number of relaxed formats like STRICT_DATE_OPTIONAL_TIME, STRICT_DATE_OPTIONAL_TIME_NANOS, those are explicit on optionality of some components.

Copy link
Member

Choose a reason for hiding this comment

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

Agreed that we probably don't want to change the definition of what STRICT_DATE_TIME means.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Seems reasonable. In this case I'll close this PR and recommend that the person who created the original issue changes their mapping to use a different format.

@github-actions GitHub Actions
Copy link
Contributor

❌ Gradle check result for d54ff3c: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@opensearch-ci-bot opensearch-ci-bot mentioned this pull request Nov 22, 2024
Open
@epugh
Copy link

epugh commented Nov 26, 2024

I wanted to follow up on @peteralfonsi comment (and thanks @peteralfonsi for the PR!). I know that strict_date_time is not the same as ISO8601, but instead is more defined by what OpenSearch project defines it. It's interesting to see that various date format standards all have, well, many flavours ;-).

I'm collecting different flavours of ISO8601 in this thread: https://bsky.app/profile/dep4b.bsky.social/post/3lbadp742pk26 ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@reta reta reta requested changes

@anasalkouz anasalkouz Awaiting requested review from anasalkouz anasalkouz is a code owner

@andrross andrross Awaiting requested review from andrross andrross is a code owner

@ashking94 ashking94 Awaiting requested review from ashking94 ashking94 is a code owner

@Bukhtawar Bukhtawar Awaiting requested review from Bukhtawar Bukhtawar is a code owner

@CEHENKLE CEHENKLE Awaiting requested review from CEHENKLE CEHENKLE is a code owner

@dblock dblock Awaiting requested review from dblock dblock is a code owner

@dbwiddis dbwiddis Awaiting requested review from dbwiddis dbwiddis is a code owner

@gbbafna gbbafna Awaiting requested review from gbbafna gbbafna is a code owner

@jainankitk jainankitk Awaiting requested review from jainankitk jainankitk is a code owner

@kotwanikunal kotwanikunal Awaiting requested review from kotwanikunal kotwanikunal is a code owner

@linuxpi linuxpi Awaiting requested review from linuxpi linuxpi is a code owner

@mch2 mch2 Awaiting requested review from mch2 mch2 is a code owner

@msfroh msfroh Awaiting requested review from msfroh msfroh is a code owner

@nknize nknize Awaiting requested review from nknize nknize is a code owner

@owaiskazi19 owaiskazi19 Awaiting requested review from owaiskazi19 owaiskazi19 is a code owner

@Rishikesh1159 Rishikesh1159 Awaiting requested review from Rishikesh1159 Rishikesh1159 is a code owner

@sachinpkale sachinpkale Awaiting requested review from sachinpkale sachinpkale is a code owner

@saratvemulapalli saratvemulapalli Awaiting requested review from saratvemulapalli saratvemulapalli is a code owner

@shwetathareja shwetathareja Awaiting requested review from shwetathareja shwetathareja is a code owner

@sohami sohami Awaiting requested review from sohami sohami is a code owner

@VachaShah VachaShah Awaiting requested review from VachaShah VachaShah is a code owner

Assignees
No one assigned
Labels
backport 2.x Backport to 2.x branch bug Something isn't working Search Search query, autocomplete ...etc
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

[BUG] strict_date_time should accept timestamps without a trailing Z or timezone offset
4 participants
@peteralfonsi @epugh @reta @andrross