Denormalization of empty string date throws UnexpectedValueException

Created on 3 July 2019, over 5 years ago
Updated 6 June 2023, over 1 year ago

When an incoming object to be unserialized contains an empty string (instead of null) for a date property it is considered invalid by the DateTimeNormalizer. Generating the error The specified date "" is not in an accepted format:
This seems to be a common case though, especially with strict type checking an empty string is a perfectly valid "no date set" condition.

I think the validation constraints should handle these cases as well. The patch should address this.

šŸ› Bug report
Status

Needs work

Version

11.0 šŸ”„

Component
SerializationĀ  ā†’

Last updated 6 days ago

Created by

šŸ‡³šŸ‡±Netherlands karel010

Live updates comments and jobs are added and updated live.
  • Novice

    It would make a good project for someone who is new to the Drupal contribution process. It's preferred over Newbie.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • šŸ‡ŗšŸ‡øUnited States smustgrave

    Think the change from #9 should be included.

    Outside of javascript files not sure we use === ""

    Tagging for novice as it should be an easy update.

  • Assigned to sourabhjain
  • šŸ‡®šŸ‡³India sourabhjain

    Let me work on this.

  • @sourabhjain opened merge request.
  • Issue was unassigned.
  • Status changed to Needs review almost 2 years ago
  • šŸ‡®šŸ‡³India sourabhjain

    Worked on #24 and rerolled the patch and created PR.

  • Status changed to RTBC almost 2 years ago
  • šŸ‡ŗšŸ‡øUnited States smustgrave

    Change looks good.

    Verified locally that 1 test fails without the fix. Data set "Empty string" throws Symfony\Component\Serializer\Exception\UnexpectedValueException : The specified date "" is not in an accepted format: "Y-m-d\TH:i:sP" (RFC 3339), "Y-m-d\TH:i:sO" (ISO 8601).

  • Status changed to Needs work almost 2 years ago
  • šŸ‡¦šŸ‡ŗAustralia larowlan šŸ‡¦šŸ‡ŗšŸ.au GMT+10

    Somehow we ended back with the #9 approach, which as pointed out (albeit rudely) in #12 is wrong, because 0 is a valid unix timestamp.

    Can we go back to #20 please.

  • šŸ‡®šŸ‡³India prem suthar Ahemdabad- Gujrat , Jodhpur - Rajsthan

    Fix the failed Patch For 10.1 version.

  • šŸ‡¦šŸ‡ŗAustralia larowlan šŸ‡¦šŸ‡ŗšŸ.au GMT+10

    I think we still need a test-case for 0 as the patch didn't fail without it.

    That probably means we need to expand the test method to accept an 'expected' denormalized value, which would default to the original value.

    @Prem Suthar please be sure to add an interdiff ā†’ when working with patches so reviewers can know what changed.

  • šŸ‡ŗšŸ‡øUnited States Kristen Pol Santa Cruz, CA, USA

    Iā€™m triaging for DrupalCon mentored contribution and reviewing as this issue is tagged novice.

    *******
    Please leave this issue for DrupalCon mentored contribution as a possible first time issue.

    *******
    Next step is to update the test per the most recent comment.

  • šŸ‡ŗšŸ‡øUnited States Kristen Pol Santa Cruz, CA, USA

    Tag normalization happening:)

Production build 0.71.5 2024