Horarios y festivos en PrestaShop: zona horaria y evaluación
Comprueba intervalos, zonas horarias PHP, cambios de hora y exclusiones de festivos. Entiende las reglas antes de programar funciones de la tienda.
Comprueba la zona horaria y las reglas exactas de programación antes de programar cuándo se activa una función de la tienda. Los límites de fecha, los horarios semanales y las exclusiones de festivos funcionan juntos solo donde el módulo los evalúa.
Qué haríamos
Empezaríamos por el resultado: cambiar un precio, mostrar contenido, reforzar un resultado de búsqueda o ajustar una promesa de entrega. Elige la vía según tu tienda actual: sus módulos y versiones, integraciones, tema, reglas guardadas, datos de festivos, mercados y el equipo que los mantiene. Un formulario de calendario o programación solo es útil cuando la función aplica las reglas necesarias.
Ensaya el cambio en una copia privada de pruebas con la misma configuración, aislada de los correos de producción y las tareas externas. Conserva los ajustes anteriores, prueba el resultado que ve el cliente y después acuerda el cambio en producción y una persona que lo compruebe. Acuerda los pasos para retirar cada función; comprueba más abajo el significado de “Always” antes de tratar un control de programación como un interruptor de apagado.
Si quieres que lo configuremos y verifiquemos por ti, PrestaShop Module Installation & Configuration Service cubre un módulo existente y su proceso acordado.
Qué controla una programación
Una programación puede limitar una función a un intervalo de fechas, un horario semanal o fechas que no sean festivos excluidos. Algunos ejemplos son una promoción entre semana, un banner en horario comercial, contenido programado y un refuerzo temporal de búsqueda. El módulo que la utiliza decide qué acción permite la programación.
El widget compartido de programación pertenece al paquete Entity Selector. Ofrece campos de fecha y hora, una línea temporal semanal recurrente y exclusiones opcionales de festivos. El paquete Public Holidays proporciona datos de festivos por país. Instalar cualquiera de los dos no programa automáticamente todos los módulos ni todas las funciones de PrestaShop.
Elige el flujo según el resultado que necesitas
| Tu necesidad | Vía y alcance admitido | Qué demostrar |
|---|---|---|
| Un refuerzo temporal de búsqueda | Smart Search Revolution ofrece un formulario de programación de refuerzos y gestión de festivos; consulta su ayuda del módulo. La implementación de selección de refuerzos descrita aquí aplica límites de fecha y hora de inicio y fin mediante SQL NOW(). Ignora los horarios semanales y las exclusiones de festivos guardados en el formulario. Confirma qué reglas aplica tu versión instalada antes de confiar en esos controles. | Usa límites de fecha para este flujo, comprueba la zona horaria de la sesión de base de datos y prueba la tienda antes de confiar en un refuerzo programado. |
| Una promoción en tu módulo de ventas actual | Sales Revolution incluye el paquete de festivos y usa sus propios campos de programación de descuentos; usa su ayuda del módulo para ese flujo. | Comprueba el precio en la página de producto, el carrito y el proceso de pago antes, durante y después de la campaña. Determina su comportamiento específico en festivos. |
| Campañas de precios puntuales o recurrentes | Smart Dynamic & Scheduled Discounts ofrece estas fechas, selección de productos y límites mínimos de precio o margen. | Previsualiza los productos elegibles y los precios finales; después prueba el vencimiento y la reversión con otros descuentos activos. |
| Un cierre que afecta a las promesas de llegada | Estimated Delivery Date combina cierres, horas límite y calendarios de transportistas con reglas de productos y existencias. | Comprueba el destino y el transportista afectados. Decide el cierre de expediciones por separado de si los clientes pueden hacer pedidos. |
| Una tarea en segundo plano debe ejecutarse a tiempo | Cron Manager ofrece programación de tareas, historial y fallos. | Confirma que la tarea se haya ejecutado y haya producido su resultado. Programar la ejecución no añade comprobaciones semanales o de festivos a una función. |
Zona horaria y horario de verano
El evaluador compartido usa la función PHP date() para la marca de tiempo proporcionada. Usa la zona horaria activa de PHP, no una zona horaria independiente guardada en cada programación. PrestaShop 1.7.8 y 9.1 establecen la zona horaria de PHP a partir de PS_TIMEZONE. Por tanto, la zona horaria del sistema operativo del servidor puede diferir de la utilizada por una solicitud que haya inicializado la tienda.
El widget administrativo muestra el día y la hora actuales del servidor. La indicación no incluye un identificador de zona horaria. Confirma la zona configurada de la tienda y la zona activa de PHP al depurar.
Los intervalos semanales son horas locales del reloj. Para una zona horaria con nombre como Europe/Warsaw, el desfase UTC cambia con el horario de verano. Una hora repetida puede coincidir dos veces con el mismo intervalo semanal, mientras que una hora local omitida no tiene ningún instante coincidente. Los datos compartidos de programación no guardan un desfase ni una regla para elegir una de las apariciones de una hora local ambigua.
Prueba fechas anteriores y posteriores a cada cambio de hora pertinente. Para una hora repetida, prueba los dos instantes UTC que corresponden al mismo minuto local programado. Para una hora omitida, prueba inmediatamente antes y después del salto. Convierte cada instante UTC explícito usando la misma zona horaria que la tienda. Comprueba por separado cron y los procesos de trabajo de larga duración: un script que no inicialice PrestaShop puede conservar una zona horaria de PHP distinta.
Intervalos de fechas, horarios semanales y límites
El evaluador compartido sigue estas reglas:
- Una programación vacía o desactivada devuelve permitido. La opción “Always” del widget desactiva la restricción de programación; no desactiva la función de negocio.
- Si existe una fecha y hora de inicio, se rechaza una fecha y hora actual anterior. Si existe una fecha y hora de fin, se rechaza una fecha y hora actual posterior. Los segundos exactos de inicio y fin están incluidos.
- Si existe una programación semanal y hoy tiene una entrada, se rechaza un día desactivado. En caso contrario, el minuto actual debe estar entre los valores inicial y final de ese día, ambos incluidos.
- Si la exclusión de festivos está activada, se proporcionan países y hay un proveedor conectado, un festivo coincidente rechaza el resultado.
- Si ninguna comprobación lo rechaza, la programación permite la acción.
Los límites de fecha, las reglas semanales y las exclusiones son acumulativos. Un festivo no puede abrir un día semanal que de otro modo esté cerrado. Una apertura semanal no puede saltarse un intervalo de fechas caducado.
La ausencia de una entrada de día semanal no significa cerrado en este evaluador: ese día no tiene restricción semanal. Guarda entradas desactivadas explícitas para los días que quieras excluir. Los valores ausentes de minuto inicial y final se establecen por defecto en 0 y 1440 para un día que tenga entrada.
El cálculo semanal usa horas y minutos sin segundos. Un valor final de 17:00 incluye todo el minuto 17:00. Un fin de fecha y hora guardado como 17:00:00 incluye ese segundo exacto, pero rechaza 17:00:01. Ten en cuenta esa diferencia al probar los límites.
Un único intervalo semanal cuyo inicio sea posterior al fin no continúa a través de medianoche. Representa una apertura nocturna en dos días con los controles que admita el módulo concreto. No supongas que interpreta de 22:00 a 02:00 como un intervalo nocturno.
Países de festivos, precedencia y datos ausentes
Las tablas compartidas usan el prefijo de tu base de datos seguido de mpr_public_holidays y mpr_public_holidays_lang. Los registros incluyen país, fecha del calendario, año, indicador de activación y tipo. Los tipos incluyen public, bank, observance, regional y custom.
La consulta de isHoliday() usa registros activos del año solicitado y de cualquiera de los países seleccionados. Seleccionar Francia y Alemania significa que un festivo coincidente de cualquiera de ellos puede excluir la fecha. No exige que el día sea festivo en ambos países.
La llamada compartida de programación no pasa una lista de exclusión de tipos de festivo. No supongas que solo cuentan los registros de tipo “public”. La consulta tampoco tiene filtro de tienda ni de región. Un registro etiquetado como regional sigue basándose en el país en esta consulta.
El modelo tiene un indicador de recurrencia, pero esta consulta comprueba la fecha y el año concretos. No extiende al año actual un registro recurrente del año pasado. Importa o mantén las fechas del año necesario y revisa tú mismo su aplicación regional.
Una exclusión de festivos sin proveedor conectado o sin países seleccionados no tiene efecto. Los registros de calendario ausentes tampoco pueden excluir un día. Un resultado vacío de festivos no demuestra que el día sea laborable. Comprueba la disponibilidad de tablas, los años importados, los indicadores de activación y los registros de la aplicación.
El paquete admite importar desde Nager.Date. Revisa el calendario importado según tu política operativa antes de confiar en él. Los datos compartidos solo afectan a los módulos que realmente llaman al proveedor.
Ejemplo de apertura entre semana y un festivo
Supongamos que un banner usa el evaluador compartido y debe aparecer de lunes a viernes de 09:00 a 17:00, excepto los festivos franceses. Mantén las fechas de prueba dentro de su intervalo de fechas, activa explícitamente cada día de lunes a viernes, desactiva el fin de semana y selecciona Francia con un proveedor conectado y un registro de festivo activo.
Un lunes ordinario dentro del intervalo de fechas, a las 08:59:59 debe rechazarse, a las 09:00:00 debe permitirse, a las 17:00:59 aún debe permitirse y a las 17:01:00 debe rechazarse: el minuto final semanal está incluido. En el festivo seleccionado, a las 09:00 debe rechazarse. El sábado también debe rechazarse. Comprueba el propio banner además de los ajustes guardados. Este escenario requiere el evaluador compartido: la vía de refuerzo de búsqueda anterior no puede aplicar estas reglas semanales y de festivos. Que un banner se oculte correctamente tampoco demuestra nada sobre la disponibilidad del proceso de pago o las expediciones del almacén.
Verifica una programación antes de confiar en ella
- Anota la tienda, la zona horaria de PHP, el horario local previsto y la versión del módulo que la utiliza. Para comprobaciones de fechas SQL, anota también la zona horaria de la sesión de base de datos.
- Comprueba la función con la programación desactivada y activada.
- Prueba inmediatamente antes, exactamente en y justo después de ambos límites de fecha y hora.
- Prueba un día semanal permitido, otro desactivado explícitamente y otro sin entrada guardada.
- Prueba los minutos de inicio y fin, medianoche y un intervalo nocturno dividido si lo necesitas.
- Prueba un festivo activo conocido para un país seleccionado, un país no seleccionado y una fecha del siguiente año natural.
- Prueba una transición de horario de verano e inspecciona por separado cualquier zona horaria de cron o de procesos de trabajo.
- Comprueba la tienda tras caducar la caché. Una programación que solo se evalúa al recibir una solicitud o mediante un proceso de trabajo surte efecto cuando se ejecuta esa evaluación. Compara una nueva solicitud de cliente con una página previamente almacenada en caché y comprueba la siguiente ejecución del proceso de trabajo cuando corresponda: una página sin cambios puede ser una salida obsoleta en lugar de una regla rechazada.
Documenta el resultado esperado para cada caso. Otros módulos pueden usar distintos evaluadores, convenciones de marcas de tiempo o momentos de captura. Confirma su comportamiento a partir de su propia ayuda e implementación.
Qué preguntar a tu desarrollador o agencia
- ¿A qué evaluador llama realmente esta función y qué controles guardados ignora?
- ¿Dónde están registrados los ajustes de zona horaria pertinentes, el desencadenante de evaluación y las reglas de caché?
- ¿Quién mantiene los años de festivos necesarios y comprueba los cierres regionales según nuestra política operativa?
- ¿Dónde están los resultados esperados y observados en la tienda, los ajustes anteriores y los pasos específicos para retirar la función?
Preguntas de los responsables de tiendas
¿Puede cada cliente ver los horarios en su propia zona horaria?
Solo si el flujo que utiliza la programación admite ese requisito. Define si una campaña sigue la hora de la tienda o la hora local de cada mercado antes de elegir la implementación; el país de un visitante no constituye por sí mismo una regla de zona horaria.
¿Cambiar un calendario de entrega actualizará los pedidos existentes?
Estimated Delivery Date guarda la estimación aceptada en el pedido. Los cambios posteriores del calendario la dejan intacta, así que gestiona por separado cualquier modificación de la promesa al cliente.
¿Y si una promoción sigue activa tras el fin previsto?
Usa el procedimiento de retirada acordado, verifica el precio real hasta el proceso de pago y registra el periodo afectado para que lo revise el personal. Comprueba la evaluación y la salida en caché antes de volver a intentar la campaña.