Scheduled trigger every 13 days Azure pipeline

I want to write add a scheduled trigger to fire a pipeline in Azure once every 13 days. I can't seem to find a answer with the normal cron jobs syntax and I've seen you can combine it with regular expressions. The starting day does not matter. I thought about something like this:

schedules:
- cron: "0 1 * * * $((((($(date +%s) / 86400) % 13))==0))"
displayName: Every 13 days execution

But I am getting a syntax error. How do I add a regex to a cron scheduled triger in azure?

If you echo the result of the regex: echo $((((($(date +%s) / 86400) % 13))==0)), you can see it works as expected, now it is about using it with the cron job in a yaml file.

Obviously, something like: 0 0 */13 * * doesn't work, because it will be on the 13th and 26th and from the 26th of a month, to the 13th of the next, is more than 13 days.

Edit:
Would 0 */312 * * * work? According to https://crontab.guru/#0_/312_** it seems like it would. I'm just unsure if it is 24 hour based and therefore never actually run? Because, well, once every 312 hours, there is never 312 hours in a day, but if doesn't interpret it like that it should be fine?
Saw a guy wrote something similar on https://stackoverflow.com/questions/4549542/cron-job-every-three-days and it got 15 upvotes.

Second edit: The /312 does not work. The frequency cannot be higher than 23, which makes sense. Don't believe everything you read on Stack

>`schedules:

• cron: "0 1 * * * $((((($(date +%s) / 86400) % 13))==0))"
  displayName: Every 13 days execution`

>But I am getting a syntax error.

This syntax error should be caused by that 6 entries are included where only 5 are needed or you are missing branches parameter in your schedules.

>The /312 does not work.

I tried this and it works fine without any error:

schedules:
  - cron: "0 */312 * * *"
    displayName: Every 13 days execution
    branches:
      include:
        - master
    always: true

What do you mean by "does not work", do you met any error message? If so, please share the error you met.

Please let me know if I am wrong, but I have come to the following conclusion:

You cannot add a regex like that into the cron section of the yaml file - however, I am not sure about this. I just couldn't figure out how to do it and didn't find any examples online or at Azure's documentation, where they use regex in the yaml file under the cron section.
2.
If you look at my edits, I tried to do cron 0 */312 * * *, and according to https://crontab.guru/#0_/312_**, it says: “At minute 0 past every 312nd hour.”, but the hours are 24-hour indexed and cron is stateless (it doesn't have know anything about previous executions, the time it ran, if they failed or not etc.) so it will never reach the 312nd hour, since the hours are actual based on the clock-hours. It doesn't provide a syntax error, it just executes every 24 hours instead. If you want to test it, I suggest you do the following:

touch /home/user/Desktop/everyminute.log
crontab -e

Add the following to the end of the line:

*/1 * * * * echo "tick $(/bin/date)" >> /home/user/Desktop/everyminute.log
*/61 * * * * echo "tack $(/bin/date)" >> /home/user/Desktop/everyminute.log
*/100 * * * * echo "tock $(/bin/date)" >> /home/user/Desktop/everyminute.log

and then do a tail -f /home/user/Desktop/everyminute.log.
You'll see the everyminute a tick with the time and when the hour has passed, you'll see a tick, tack and tock hit at the same time (after a hour), which confirms the fact, that it is 60 indexed (when minutes) and I assume the same in hours.

3. So, I ended up doing a hack. I add: cron 0 13 * * 0 to the yaml file, which runs every week on Sunday, and in my actual bash script that is executed in the pipeine, I added if [ $(($(date +%V) % 2)) -eq 0 ] on line 1, to check if the week is even or odd. So the pipeline is still executed every week (it takes virtually zero ressources to just run it), but it only executes the job, if the week is even. Btw, this also means that it is every 14th day and not every 13th day, but I could use that as well.