stsebas2

Hi @milui,

I’ve been experiencing the exact same issue and tracked down the root cause.

Root Cause

The bug is in includes/js/src/parts/calendar.js, lines 141-142:

  let month_real_value = monthpicker.val() + '-01';
  fp.setDate( new Date( month_real_value ) );

After flatpickr initialization, monthpicker.val() returns the localized month name
(e.g., “Abr 2026” in Spanish, “Apr 2026” in English with “M Y” format). This value is
appended with “-01” and passed to JavaScript’s new Date().

The problem: new Date() cannot reliably parse strings like “Abr 2026-01” (non-English)
or even ambiguous English formats. When parsing fails, it defaults to January 1.

Tested results:

• new Date("Mar 2026-01") → March (works — “Mar” is universal)
• new Date("Abr 2026-01") → January (fails — “Abr” is Spanish for April)
• new Date("Apr 2026-01") → April (works — English abbreviation)
  
  This explains why it happens “every second time” — it fails only for months whose
  abbreviated name differs from English (in Spanish: Jan/Ene, Apr/Abr, Aug/Ago, Dec/Dic).

Fix

Replace the localized text with numeric data attributes the server already provides:

  // Before (broken):
  let month_real_value = monthpicker.val() + '-01';

  // After (works for all locales):
  let month_real_value = calendar.attr('data-year') + '-' +
    String(calendar.attr('data-month')).padStart(2, '0') + '-01';

This generates ISO format “2026-04-01” which new Date() parses correctly in any language.

Apply the fix in both files:

• includes/js/src/parts/calendar.js (line 141)
• includes/js/events-manager.js (line 3564)
  

Tested with WP Safe Mode (only Elementor + Events Manager active), WordPress 6.9.1,
Events Manager 7.2.3.1, locale es_ES.

@msykes — would it be possible to include this fix in the next release?