In Part 1, we covered the basics of inserting dynamic dates into your Zendesk macros, triggers and automations. In this article, I’ll show how to do some super-neat tricks that will really impress your customers and give them that delightful feeling of personable customer service.

Advanced dynamic dates

Use case:

Current day plus 3 days, excluding Saturday and Sunday [quite advanced]

This is a really neat block of code. Imagine your team answers customer emails Monday to Friday, and has an SLA of three working days. Assuming today is Friday, simply telling a customer that you’ll get back to them in three days doesn’t work, as three days from Friday is Monday. This string will specify three working days from Friday, which will be Wednesday.

String:

{% assign today = 'now' | date: '%A' %}
{% if today == 'Wednesday' %}
{{ 'now' | date: '%s' | plus:432000 | date: '%Y-%m-%d' }}
{% elsif today == 'Thursday' %}
{{ 'now' | date: '%s' | plus:432000 | date: '%Y-%m-%d' }}
{% elsif today == 'Friday' %}
{{ 'now' | date: '%s' | plus:432000| date: '%Y-%m-%d' }}
{% elsif today == Saturday' %}
{{ 'now' | date: '%s' | plus:345600| date: '%Y-%m-%d' }}
{% else %}
{{ 'now' | date: '%s' | plus:259200 | date: '%Y-%m-%d' }}
{% endif %}

‍

Output:

2023-06-28 (the 28th was a Wednesday)

This formula works on the following basis: If today is Wednesday, three days into the future will be Saturday. So the formula tells Zendesk that if it’s Wednesday today, it should simply add 5 days (the three days you want, plus two for the weekend). The five days are calculated in seconds: 60 seconds x 60 minutes x 24 hours x five days = 432,000 seconds.

The same goes for if today is Thursday, except that three days into the future would be Sunday. Again, five days are added.

Friday is similar, although you need to think about it differently. It’s not that three days after Friday is a weekend, as it’s not (it’s Monday). But those three days do include Saturday and Sunday so, again, we need to add on two more days to account for this.

If today is Saturday, the formula tells Zendesk to add four days. Three for the three weekdays we want, and one for Sunday.

For Sunday, Monday and Tuesday, we can simply stick to telling Zendesk to add three days, as these days of the week are not followed by a weekend day.

If you want to adjust the three days to another time frame, just use 86,400 multiplied by the number of working days into the future you want. You’ll then need to add on two more days (172,800, to account for the weekend) to that final number, as we have above. You’ll also need to consider whether Sunday, Monday or Tuesday will need to have their own durations specified.

Bear in mind that if you are doing a prolonged time period such as 10 working days, you’ll need to calculate how many weekend days that will include for each possible start day. For example, if it’s Wednesday today and you want your macro to display 10 working days from now, that will include two weekends (four days total), so you’ll need to add 345,600 to your desired number of working days.

‍

A note on time zones and daylight savings

As you may notice when you start testing these, Zendesk calculates all times in UTC (Coordinated Universal Time), which is also known as GMT.

We have some ability to adjust for this when necessary, although not as simply or thoroughly as we’d like. In any of the above strings, we can add a sub-string that adds or subtracts the amount of seconds required to shift from UTC, which is +0 time zone, to say, Berlin time, which is UTC + 2 during summer. 

To do this, let’s look at our second example string from Part 1; current date and time

{{'now' | date:'%Y-%m-%d %H:%M'}} produces 2023-06-23 13:20

Now, right after “date:”, we add “ '%s' | plus:7200 | date:” so that we now have

{{'now' | date:'%s' | plus:7200 | date:'%Y-%m-%d %H:%M'}} which produces 2023-06-23 15:20

The core function we have done here is to tell Zendesk to add 7,200 seconds to the time. 7,200 seconds is two hours, the difference between UTC and Berlin in the summertime.

There is one obvious downside to this, a simple solution to which I could not find. When your country changes to or from daylight savings hours, you’ll need to add or subtract 3,600 (an hour) to keep your output accurate as your country moves an hour closer or further from UTC.

It’s worth bearing in mind that considering your time zone is only really required when you need to display a time (in hours) to the end user. If you are just using the date function then, unless your team is working close to midnight every night, or you’re based in Australasia or Eastern Asia, using the UTC date will be perfectly sufficient for your needs.

Now that you’ve learned how to tell Zendesk to compute the exact date you want, it’s time we cover how to format these dates in a much friendlier way. Check out Part 3 to learn how to display these dates in just about any way you could wish.