When working iwth specific date strings like 01-01-2024 or 04/03/2022, the default PHP date parsing works differently depending on the use of dashes vs slashes:

• 04/06/2025 is interpreted month-first as April 6, 2025 (MM/DD/YYYY)
• 04-06-2025 is interpreted day-first as June 4, 2025 (DD-MM-YYYY)

This can cause confusion since some LiveWhale contexts allow using either dashes or slashes (e.g., widget settings) and others require dashes (e.g., the REST API). One way around this ambiguity is to use YYYY-MM-DD when setting up API integrations or overriding widget settings.

However, we don’t want developers thinking hard about the difference between 04-06 and 04/06. So, LiveWhale 2.10.0+ has a configuration setting which, when enabled, bypasses this dashes-vs-slashes question and always use one format across all settings and filters.

$_LW->CONFIG['FILTER_USING_LOCAL_DATE_FORMAT']=true; // When true, widgets and API requests will treat all start and end dates as MM-DD-YYY (in US timezones) and DD-MM-YYYY in (European/Australian timezones), regardless of whether dashes or slashes were used.

With this setting enabled in global.config.php, all date strings will be treated as:

• US timezones: month-first, i.e., MM-DD-YYYY or MM/DD/YYYY
• European/Australian timezones: day-first, i.e., DD-MM-YYYY or DD/MM/YYYY

We expect this to become the default behavior in LiveWhale 3.0 but have implemented it as a configurable setting in the meantime to preserve backwards-compatibility for existing widgets and API requests across LiveWhale 2.x.