Power Automate: dayOfWeek Function

When you work with dates in Power Automate, sooner or later you need to know which day of the week a date falls on. The "dayOfWeek" function returns an integer that represents the day of the week for a date, where 0 is Sunday, 1 is Monday, ending in 6, a Saturday.

It is a small function with one job, and it pairs naturally with the "dayOfMonth" function and the "dayOfYear" function to slice a date into the parts you actually care about. It also has one trap that catches almost everyone, so let's take a look.

Usage

It follows a simple pattern.

1. Date

dayOfWeek('<timestamp>')

There is only one parameter. No format, no locale, no time zone. We will come back to that, because it matters more than it looks.

A simple example

dayOfWeek('2019-10-28T10:10:00Z')

will return

1
So we know it's a Monday

Please be aware that the reference material, Microsoft names objects like '2019-10-28T10:10:00Z' as timestamps. I prefer calling them "Date" to avoid confusion with the UNIX timestamp, commonly used in APIs, to represent the number of seconds elapsed since Jan 01 1970 (UTC).

Today's day of the week

Combine it with the "utcNow" function to get the current day.

dayOfWeek(utcNow())

will return the day number for today, in UTC

Read that last part carefully. In UTC. It is the source of most of the surprises with this function, and the next section explains why.

A value from a previous action

You can pass in anything that holds a valid date, like a SharePoint date column or a variable.

dayOfWeek(triggerOutputs()?['body/DueDate'])

The return value is always an integer, never a string, so you can compare it directly in your conditions without converting anything.

Date without a time

If you pass a date with no time component, Power Automate treats it as midnight.

dayOfWeek('2019-10-28')

will return

1

That is convenient, but combined with a time zone conversion later it can flip the day on you. Include the time portion whenever precision matters.

Edge Cases

Sunday is 0, so "greater than 5" is a bug

This is the most common mistake with the "dayOfWeek" function, and Microsoft calls it out in their own documentation. If you want to catch the weekend, it is tempting to write a condition like dayOfWeek(utcNow()) > 5. That catches Saturday, which is 6, and quietly misses Sunday, which is 0.

Check for both days explicitly instead.

or(equals(dayOfWeek(utcNow()), 0), equals(dayOfWeek(utcNow()), 6))

The time zone decides the answer

The "dayOfWeek" function reads the date exactly as you hand it over. It does no time zone maths of its own, so the zone of the value you pass in is the zone of the answer you get back.

That means dayOfWeek(utcNow()) gives you the day of the week in UTC, not the day of the week where your users are. A flow running at 20:00 on a Saturday in Los Angeles is already 04:00 on Sunday in UTC, so a weekend check built on the UTC value sees Sunday. Someone in Lisbon or São Paulo gets a different flavor of the same problem.

If the business rule is local, convert the value into the local zone first and then extract the day.

dayOfWeek(convertFromUtc(utcNow(), 'GMT Standard Time'))

The "convertFromUtc" function returns the local time without the UTC offset, which is exactly what you want to feed a function that has no time zone awareness. You can also use the "Convert Time Zone" action if you prefer to do it as a visible step in the flow.

Time zones use Windows names, not IANA names

When you convert, Power Automate expects the Windows time zone names, like 'GMT Standard Time' or 'Pacific Standard Time'. It does not understand the IANA names that most developers reach for by reflex, like 'Europe/Lisbon' or 'America/Los_Angeles'. Getting this wrong fails the conversion, not the "dayOfWeek" function, but it looks like the same bug from the outside.

Limitations

It returns a number, not a day name

Since it returns an integer, you need to provide the translation to something that the end user will understand. It can be tricky for apps in multiple languages, but always translate the value. The user doesn't know that 0 means Sunday.

If a day name is all you need, you don't have to build the translation yourself. See the recommendation below.

No format, locale, or time zone parameter

Most of the neighboring date functions take an optional format argument, and the "formatDateTime" function even takes a locale. The "dayOfWeek" function takes none of them. It accepts one date and returns one integer. Anything else, like converting the zone or formatting the output, happens in a separate step before or after the call.

The first day of the week is not configurable

Sunday is 0, permanently. There is no setting that shifts the week to start on Monday, even though that is the first day of the week in most of Europe. If you need an ISO style week where Monday is 0, do the arithmetic yourself.

mod(add(dayOfWeek(utcNow()), 6), 7)

Monday now returns 0, and Sunday returns 6

The date itself is not really a limitation

Contrary to what you may expect, there's no practical limit to the date that you can use. You can do things like:

dayOfWeek('1000-12-30T00:00:00Z')

and you'll get

2
So we know it's a Tuesday

The value only has to be a valid ISO 8601 date. If your source data arrives in some other shape, like '28/10/2019', run it through the "parseDateTime" function first to bring it into a format the engine understands.

Real-world examples

Skipping the weekend in a scheduled flow

The classic use. You have a daily Recurrence and you don't want it doing anything on Saturday or Sunday.

not(or(equals(dayOfWeek(convertFromUtc(utcNow(), 'GMT Standard Time')), 0), equals(dayOfWeek(convertFromUtc(utcNow(), 'GMT Standard Time')), 6)))

Put this in a trigger condition on the Recurrence rather than in a "Condition" action inside the flow. The run then never starts on a weekend, so it doesn't count against your quota. A Condition inside the flow works too, but you pay for the run either way.

Do keep in mind that this catches weekends only. Public holidays are not weekends, and no function knows about them, so you'll need a list somewhere if those matter to you.

Sending a report only on Mondays

equals(dayOfWeek(convertFromUtc(utcNow(), 'GMT Standard Time')), 1)

Same idea, but for a single day. Convert first, compare second.

Filtering a list down to weekdays

You can also use it inside a "Filter Array" action to keep only the items that fall on a working day.

@and(greater(dayOfWeek(item()?['DueDate']), 0), less(dayOfWeek(item()?['DueDate']), 6))

Troubleshooting Common Errors

The datetime string must match ISO 8601 format

Cause: The value you passed is not a date the engine can parse, so it gives up. A string like '28/10/2019' or 'October 28, 2019' will do it, and so will a value from a column you assumed held a date but doesn't.

Solution: Bring the value into ISO 8601 shape before it reaches the "dayOfWeek" function. The "parseDateTime" function does this and takes a locale, so it knows whether 03/04 means March 4th or April 3rd.

dayOfWeek(parseDateTime('28/10/2019', 'en-GB'))

The flow fails on save instead of at run time

Cause: This one confuses people, because the same bad date behaves in two different ways. If the date is a constant that you typed into the expression, Power Automate can see it is invalid before the flow ever runs, so it refuses to save and reports an "InvalidTemplate" error. If the date comes from a variable, a trigger, or a previous action, it can only fail at run time with an "ExpressionEvaluationFailed" error.

Solution: Nothing is broken. Read the error where it appears. A save time failure means the literal in your expression is wrong. A run time failure means the data flowing into it is wrong, which is a different problem in a different place.

An empty SharePoint date column breaks the expression

Cause: An empty date column does not always come through as null. It often arrives as an empty string, and an empty string is not a valid date.

Solution: This is why wrapping it in the "coalesce" function doesn't save you, since "coalesce" only handles null. The "empty" function returns true for both null and an empty string, so use that instead.

if(empty(triggerOutputs()?['body/DueDate']), null, dayOfWeek(triggerOutputs()?['body/DueDate']))

Recommendations

Here are some things to keep in mind.

Convert to local time before you call it

If the business meaning of "the day of the week" is local, convert the date into the local zone first and then extract the day. To get the best results, please be sure that you know which zone the value you're passing represents. If you're storing your local time somewhere, use the "Convert Time Zone" action to convert it before providing the value to the "dayOfWeek" function. If you don't, you may be returning invalid values to the end user.

Don't do the maths, just translate the value

In some cultures the first day of the week is Monday and not Sunday, so one would expect 0 to be Monday. Don't do any maths in trying to convert to your preferred system. Just translate the value provided, and you're good to go.

If you only need the day name, use formatDateTime instead

This is the shortcut most people miss. If you want "Monday" rather than 1, you don't need the "dayOfWeek" function at all, and you certainly don't need to build an array of day names to look the number up in.

formatDateTime('2019-10-28T10:10:00Z', 'dddd')

will return

Monday

Use 'ddd' for the short form, and pass a locale as the third argument to get the name in another language. Reach for the "dayOfWeek" function when you need to compare, and the "formatDateTime" function when you need to display.

Always add a comment

Adding a comment will help others understand your formula. Indicate what the function is doing and why, especially when the expression wraps a time zone conversion around it. A short note like "skip weekends, in Lisbon time" saves your future self a lot of guessing.

Final Thoughts

The "dayOfWeek" function does one job well. It hands you the day of the week as a number, and it trusts the date you give it completely. Convert the date into the right time zone first, remember that Sunday is 0 and not 7, and reach for the "formatDateTime" function when you want a name instead of a number. Get those three things right, and the rest is easy.

Sources

• Microsoft's "dayOfWeek" Function Reference
• Expression cookbook for cloud flows
• Cloud flow error code reference

Back to the Power Automate Function Reference

Photo by Charles on Unsplash