# Rest V2 Bug with Custom Field Dates in apps with Day/Month/Year formatting **URL:** \ **Category:** API Q&A\ **Tags:** bug\ **Created:** [February 10, 2026, 5:08pm UTC](https://integration.keap.com/t/rest-v2-bug-with-custom-field-dates-in-apps-with-day-month-year-formatting/93936 "2026-02-10T17:08:31Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Timothy\_Withers](https://avatars.discourse-cdn.com/v4/letter/t/838e76/32.png) [@Timothy\_Withers](https://integration.keap.com/u/Timothy_Withers)\ **Post date:** [February 10, 2026, 5:08pm UTC](https://integration.keap.com/t/rest-v2-bug-with-custom-field-dates-in-apps-with-day-month-year-formatting/93936/1 "2026-02-10T17:08:31Z")
When creating a new contact, or updating an existing one that has a DATE type custom field, everything works fine in XML and REST V1 and V2 **as long as the app has US style dates: month/day/year.** When the app is using **non-US style dates (day/month/year)**, it works fine on XML and REST v1. On V2, it flips the day and month (if it can be flipped), and stores the incorrect date. Example: POST /v2/contacts `{“email_addresses”:[{“email”:”hello@plusthis.com”,”field”:”EMAIL1”}],”given_name”:”Hello”,”family_name”:”PlusThis”,”custom_fields”:[{“id”:75,”content”:”2027-02-10”}}}` > The contact is created and the custom field is set to 2027-10-02 > Full response: ```json { "id":"82135", "family_name":"plusthis", "given_name":"hello", "preferred_locale":null, "addresses":[ ], "notes":null, "owner_id":null, "prefix":null, "birth_date":null, "origin":null, "suffix":null, "utm_parameters":[ ], "social_accounts":[ ], "contact_type":null, "spouse_name":null, "update_time":"2026-02-10T17:01:58.691Z", "company":{ "id":null, "company_name":"" }, "leadsource_id":null, "links":[ ], "job_title":null, "anniversary_date":null, "email_addresses":[ { "email":"hello@plusthis.com", "field":"EMAIL1", "opt_in_reason":null, "is_opt_in":false, "email_opt_status":"NON_MARKETABLE" } ], "tag_ids":[ ], "website":null, "create_time":"2026-02-10T17:01:59.000Z", "custom_fields":[ { "id":"52", "content":null }, { "id":"54", "content":null }, { "id":"56", "content":null }, { "id":"69", "content":null }, { "id":"65", "content":"None" }, { "id":"131", "content":null }, { "id":"144", "content":null }, { "id":"142", "content":null }, { "id":"129", "content":null }, { "id":"146", "content":null }, { "id":"148", "content":null }, { "id":"150", "content":null }, { "id":"152", "content":null }, { "id":"154", "content":null }, { "id":"156", "content":null }, { "id":"158", "content":null }, { "id":"160", "content":null }, { "id":"75", "content":"2027-10-02T04:00:00.000Z" }, { "id":"77", "content":null }, { "id":"79", "content":null }, { "id":"81", "content":null }, { "id":"83", "content":null }, { "id":"85", "content":null }, { "id":"87", "content":null }, { "id":"89", "content":null }, { "id":"119", "content":null }, { "id":"121", "content":null }, { "id":"51", "content":null }, { "id":"127", "content":null }, { "id":"133", "content":null }, { "id":"125", "content":null }, { "id":"135", "content":null }, { "id":"137", "content":null }, { "id":"139", "content":null } ], "source_type":"API", "middle_name":null, "time_zone":null, "fax_numbers":[ ], "phone_numbers":[ ], "referral_code":null, "score_value":"0", "preferred_name":null } ``` PATCH /v2/contacts/82135 `{“custom_fields”:[{“id”:75,”content”:”2027-02-10”}]}` > The custom field is updated to 2027-10-02. If we do the full ISO 8601 string, it is the same result `{“custom_fields”:[{“id”:75,”content”:”2027-02-10T05:00:00.000Z”}]}` > The custom field is updated to 2027-10-02. If the month and day are not flippable, it works as it should: `{“custom_fields”:[{“id”:75,”content”:”2027-02-15”}]}` > This is stored as the correct date: 2027-02-15. If this could be prioritized and resolved, we would appreciate it. We are having to fall back to REST v1 across many of our apps and tools that offer the ability to store dates due to this bug. ---
**Author:** ![Jeffrey\_Chimene](https://avatars.discourse-cdn.com/v4/letter/j/d6d6ee/32.png) [@Jeffrey\_Chimene](https://integration.keap.com/u/Jeffrey_Chimene)\ **Post date:** [February 10, 2026, 5:35pm UTC](https://integration.keap.com/t/rest-v2-bug-with-custom-field-dates-in-apps-with-day-month-year-formatting/93936/2 "2026-02-10T17:35:40Z")
This is a consequence of deciding everything shall be 8601. DATE\_ATOM seems baked in. ---
**Author:** ![OmarAlmonte](https://sea1.discourse-cdn.com/flex019/user_avatar/integration.keap.com/omaralmonte/32/15105_2.png) [@OmarAlmonte](https://integration.keap.com/u/OmarAlmonte)\ **Post date:** [February 10, 2026, 6:54pm UTC](https://integration.keap.com/t/rest-v2-bug-with-custom-field-dates-in-apps-with-day-month-year-formatting/93936/3 "2026-02-10T18:54:46Z")
Hi @Timothy_Withers and @Jeffrey_Chimene. Appreciate the detailed feedback. I’ll bring this up internally and follow up with you. ---
**Author:** ![OmarAlmonte](https://sea1.discourse-cdn.com/flex019/user_avatar/integration.keap.com/omaralmonte/32/15105_2.png) [@OmarAlmonte](https://integration.keap.com/u/OmarAlmonte)\ **Post date:** [February 11, 2026, 6:28pm UTC](https://integration.keap.com/t/rest-v2-bug-with-custom-field-dates-in-apps-with-day-month-year-formatting/93936/4 "2026-02-11T18:28:04Z")
@Timothy_Withers @Todd_Stoker @Jeffrey_Chimene We’ll prioritize this and aim to have it done by the beginning of March. I’ll keep you posted if anything changes. ---
**Author:** ![Jeffrey\_Chimene](https://avatars.discourse-cdn.com/v4/letter/j/d6d6ee/32.png) [@Jeffrey\_Chimene](https://integration.keap.com/u/Jeffrey_Chimene)\ **Post date:** [February 12, 2026, 12:23am UTC](https://integration.keap.com/t/rest-v2-bug-with-custom-field-dates-in-apps-with-day-month-year-formatting/93936/5 "2026-02-12T00:23:45Z")
I think we’re stuck with 8601. Even treating it as a Java serializable Calendar class, we’re left with 8601 on the wire. Even if you asked for the application’s date format, and it wasn’t in 8601, you won’t be able to send the date. This has to happen on the trip from the database to the Thryv UI. If it’s from the database to some middleware, the conversion will have to happen on that side. FWIW, I expect by now you’re running through some Java Bean annotated code. ---
**Author:** ![OmarAlmonte](https://sea1.discourse-cdn.com/flex019/user_avatar/integration.keap.com/omaralmonte/32/15105_2.png) [@OmarAlmonte](https://integration.keap.com/u/OmarAlmonte)\ **Post date:** [March 6, 2026, 8:42pm UTC](https://integration.keap.com/t/rest-v2-bug-with-custom-field-dates-in-apps-with-day-month-year-formatting/93936/6 "2026-03-06T20:42:58Z")
@Timothy_Withers @Todd_Stoker @Jeffrey_Chimene The issue has now been resolved. Thanks again for your patience and for helping us identify it! ---
**Author:** ![Jeffrey\_Chimene](https://avatars.discourse-cdn.com/v4/letter/j/d6d6ee/32.png) [@Jeffrey\_Chimene](https://integration.keap.com/u/Jeffrey_Chimene)\ **Post date:** [March 6, 2026, 9:57pm UTC](https://integration.keap.com/t/rest-v2-bug-with-custom-field-dates-in-apps-with-day-month-year-formatting/93936/7 "2026-03-06T21:57:22Z")
@OmarAlmonte Can you provide some details? Thanks ---
**Author:** ![OmarAlmonte](https://sea1.discourse-cdn.com/flex019/user_avatar/integration.keap.com/omaralmonte/32/15105_2.png) [@OmarAlmonte](https://integration.keap.com/u/OmarAlmonte)\ **Post date:** [March 9, 2026, 1:20pm UTC](https://integration.keap.com/t/rest-v2-bug-with-custom-field-dates-in-apps-with-day-month-year-formatting/93936/8 "2026-03-09T13:20:10Z")
@Jeffrey_Chimene When an app was configured with a non-US date locale, the V2 API was incorrectly reinterpreting dates that were already in ISO 8601 format (yyyy-MM-dd). In some cases, it swapped the month and day as if the date needed locale conversion, even though ISO 8601 should always be interpreted as year-month-day. That’s why a date like 2027-02-10 (Feb 10) was stored as 2027-10-02 (Oct 2), while 2027-02-15 remained correct since 15 can’t be interpreted as a month. The issue only affected the V2 API, XMLRPC and REST V1 were not impacted. The V2 API now correctly recognizes ISO 8601 formatted dates and preserves them as-is without applying locale-based reinterpretation. This fix applies to custom date fields for both Contacts and Companies.