This is a reposting of the announcement on the HubSpot Developer Changelog, if there are any differences between this post and the version on the changelog, the changelog is the source of truth.
The datetimetformat, between_times, unixtimestamp, format_date, format_datetime and format_time HubL filters 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, Jun 10, 2024 will return 5/30/24 (the current date). On December 30, 2024 Jun 10, 2024 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.
This change **bleep** and looks likely to mean that I will need to re-write a large section of our website. We currently rely on the unixtimestamp function to return us the current dates unix timestamp. With your change we can’t do that any longer.
Do you have any functions that will let us return the current date/time either in unix timestamp format or in a format that we can then use the unixtimestamp function that will work given the changes you are making.
Hey there @SParry , sorry to hear this is disruptive to your project.
Yes we do have functions and default variables for getting the current day, and the current time. today() combined with unixtimestamp() is all you need if you just need todays date.
Optionally this also enables you to base the date on a timezone.
The code for getting today and the unix timestamp, and the output result
Additionally you can get the current datetime object using the time zone defined in the account’s settings using local_dt.
If you are doing logic based on the actual time in the day - you should use JavaScript for getting the datetime instead otherwise you’re hurting your page’s performance since local_dt will return a different value literally every time the page is accessed since it is rare any two viewers will view the page at the same exact second. This means this can’t be cached, and your page can’t be fully prerendered, it can only be at most partially prerendered.
Let’s say you’re doing like an event listing and you want to say mark an event as a past event, the literal minute the event is scheduled to end, vs just letting it continue displaying as upcoming for the rest of the day. You can use JavaScript to determine if the event is upcoming or past.
In the example below we’re grabbing the current date time in unix format and printing it to the output div.
Let’s say you just need to add a CSS class to an element if the current time is later than the end datetime - all you need to do is if the event is today, add a data attribute to your HTML that has your end datetime, in your JavaScript grab that attribute and see if it’s less than the current date time, if so, add the class or add any html you want to add to indicate it’s a past event.
This makes it so your page is cacheable and fully prerenderable, and in the unlikely worst-case scenario a user with JavaScript disabled in their browser - will at worst just see an event that happened today as still possibly upcoming, they would likely be checking the times of the event anyways so this doesn’t likely matter that much anyways.
The only time that this would be a significant issue is if for example you can’t have an item appear in your code until after a certain date/time. For example say you want to display a div at the time of a product release, and you can’t just visually hide it and then toggle it’s visibility because the company is concerned about someone spotting the information in the source code.
That’s a time when using local_dt is an ideal choice. Yes, the page can’t be cached, the page can’t be fully prerendered - but given that scenario of a product release, you also don’t really want that to happen otherwise the HTML wouldn’t get the update right on time.
Thanks for the explanation Jon.
Unfortunately today() doesn’t get the job done in our case since it doesn’t include the current time. Also using local_dt won’t work for us because we have webinars and events that are happening in multiple timezones. So the need is to get the users current time.
Using javascript would bring in the need for a lot of extra code on the page not just in javascript but needing to have extra html to accommodate the changes we need to make to the template. This would be absolutely detrimental to the seo of the page which really screws us. At that point pre-rendering is the least of our problems.
We have extensively tested page speed on our site with pre-rendered and non pre-rendered pages and there is a negligible difference if at all. So using a function that stops pre-rendering is not a problem for us.
I have no issue with the change HubSpot are making, I get that it could give back an unexpected result. But what about us developers that are expecting that. Can’t we get a new function that would give us the current unixtimestamp. Or a function that would give us the current date AND time as an object that we can use with how the unixtimestamp will now behave. It’s obviously possible because that is how the unixtimestamp function behaves now.
@jmclaren I was actually over complicating things. I alway forget that the current unixtimetamp is the same no matter where you are in the world. So based on that I can just use this to do the same thing…
I appreciate you taking the time to reply. I started to second guess myself on that.
Others may similarly get confused on that, so by replying with this you’re helping them too.
