The datetimetformat, between_times, unixtimestamp, format_date, format_datetime and format_time HubL filters and functions now display warnings if they are called with a null argument. Currently, when a null argument is passed to them, the current date and time is substituted. This behavior is not something developers would expect and can have unexpected side-effects.
What's happening?
Starting on September 30, 2024, the date and time substituted for null values will stop updating and will always return September 30, 2024 00:00 UTC.
For example, on May 30, 2024, {{ null | format_date(short) }} will return 5/30/24 (the current date). On December 30, 2024 {{ null | format_date(short) }} will return 9/30/24 (the deprecation date).
This change is intended to make errors more visible when null values are passed into these filters. It's easy to pass a bad value into these filters and not notice because it displays the current date.
Defaulting to the current date also unintentionally prevented pages from being fully pre-rendered since the date and time changes on every execution. This change fixes that.
If you were relying on this behavior there are alternatives:
- Use the
local_dtHubL variable which returns the current date and time using the time zone specified in the account's settings. - Use the
today()function which gets the current day but does not get the current time. - Use JavaScript to get the current date and time - handle any logic client-side. This option does not require
local_dtor thetoday()function meaning that it does not prevent caching and full pre-rendering.
Questions or comments? Join us in the developer forums.