# Issue with Calendar Date Ranges - Invalid “error” Status Entry Causing Price Calculation Failure

**URL:** <https://community.hivepress.io/t/issue-with-calendar-date-ranges-invalid-error-status-entry-causing-price-calculation-failure/17891>\
**Category:** Bug Reports\
**Created:** [August 10, 2026, 1:46pm UTC](https://community.hivepress.io/t/issue-with-calendar-date-ranges-invalid-error-status-entry-causing-price-calculation-failure/17891 "2026-08-10T13:46:57Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Fabrizio](https://community.hivepress.io/letter_avatar_proxy/v4/letter/f/8dc957/32.png) [@Fabrizio](https://community.hivepress.io/u/Fabrizio)\
**Post date:** [August 10, 2026, 1:46pm UTC](https://community.hivepress.io/t/issue-with-calendar-date-ranges-invalid-error-status-entry-causing-price-calculation-failure/17891/1 "2026-08-10T13:46:57Z")

</div>

Dear HivePress Support Team,

I hope this message finds you well. I’m writing to report an issue I’ve encountered with the date range calendar functionality in HivePress.

### **Problem Description**

When adding date ranges with custom prices to the booking calendar, I noticed that one of the ranges was automatically saved with:

- **Label:** `"Solo data di fine\n"` (which translates to “End date only”)

- **Status:** `"error"`

This invalid entry (with `status:"error"`) is being saved in the `data-ranges` attribute and is causing the following issues:

1. **The calendar fails to initialize properly** when JavaScript attempts to modify or read this data

2. **Price calculations break** because the system cannot parse the invalid label as a numeric value

3. **The booking form becomes unresponsive** in certain cases when users try to select dates

### **Technical Details**

The problematic entry in the `data-ranges` JSON appears as:

json

```auto
{
  "start": 1786233600,
  "end": 1786320000,
  "label": "Solo data di fine\n",
  "status": "error"
}

```

### **Expected Behavior**

- Range entries with `status:"error"` should either be:

### **Questions**

1. Is there a specific scenario where `status:"error"` is intentionally saved for date ranges?

2. Should this be handled by a filter that excludes `status:"error"` entries before rendering?

3. Is there a recommended way to programmatically clean up these invalid entries?

### **Temporary Workaround**

Currently, the only way to resolve this issue is to:

1. Manually remove the invalid range from the database via SQL query

2. Or use JavaScript to filter it out (which interferes with calendar initialization)

Neither solution is ideal for a production environment.

I would greatly appreciate your guidance on the proper way to handle this issue. Is there a filter hook I can use to exclude `status:"error"` entries, or should this be fixed at the core level?

Thank you for your time and assistance. I look forward to your response.

Best regards,

---

<div class="post-metadata">

**Author:** ![kseniia](https://community.hivepress.io/user_avatar/community.hivepress.io/kseniia/32/13513_2.png) [@kseniia](https://community.hivepress.io/u/kseniia)\
**Post date:** [August 10, 2026, 2:09pm UTC](https://community.hivepress.io/t/issue-with-calendar-date-ranges-invalid-error-status-entry-causing-price-calculation-failure/17891/2 "2026-08-10T14:09:00Z")

</div>

Hi,

Thanks for the report.

Could you please share the detailed steps to reproduce the issue locally? You can either provide a step-by-step guide or record a short screencast to help us understand the issue better.

If possible, please also include your Bookings settings in the screencast or screenshots, as this may help us identify the cause more quickly.

---

<div class="post-metadata">

**Author:** ![system](https://community.hivepress.io/user_avatar/community.hivepress.io/system/32/13990_2.png) [@system](https://community.hivepress.io/u/system)\
**Post date:** [September 9, 2026, 2:09pm UTC](https://community.hivepress.io/t/issue-with-calendar-date-ranges-invalid-error-status-entry-causing-price-calculation-failure/17891/3 "2026-09-09T14:09:25Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.