Excel Date changes in Power Automate

[Pstork1]

Sometime around January 15, 2021 a change was made to the List Rows action in the Excel Online (Business) connector that stopped bringing dates in as Serial dates and started bringing them in as ISO 8601 formatted strings.    If you have existing flows that were written prior to January 15th there is a good chance that this change will break your flow. This blog will explain the background behind Serial dates in Excel, explain what you can expect going forward for Excel fields formatted as dates, and provide some helpful formulas that will let you convert dates if necessary.

Serial Dates Explained

Let’s start with a little background.  Cells in an Excel Table that are formatted as Long Date, Short Date, Time, or with one of the Custom time and date formats store their values as a Serial Date. Serial dates represent the number of days (and fractional days) that have passed since January 1, 1900. The time portion is stored as a fraction between 0.0 and 0.99999, where:

• 0.0 is midnight 00:00:00 (hours:minutes:seconds)
• 0.5 is noon 12:00:00 (12 p.m.)
• 0.99999 is 23:59:59

Note: For calculation purposes we’ve always used 12/30/1899. This is because January 1 = 1 so the 0 day is actually 12/31/1899. We have to subtract one more because 1900 didn’t have a February 29th for leap year and the formula assumes that it did. So for calculations you are off by 2 days automatically.

In the past Dates, Times, and custom formatted dates where brought into Power Automate from Excel using a List Rows action as the actual serial date stored in Excel. If you look at the example below you can see the serial dates in the JSON.

New Excel Online List Rows Behavior

The List Rows action in the Excel Online connector now brings Dates, Times, and custom formatted dates into Power Automate formatted as ISO 8601 Dates. Here’s a screenshot of the previous List rows action when I ran it today.

As you can see the dates are now listed in a format that is directly readable without doing extensive calculations.  Since Excel reports Dates and Times in a time zone neutral format all Dates and Times are considered Universal Time Code (UTC) for ISO 8601. This explains the '”Z” at the end. But whether the cell was formatted as Time only, Date only or a custom Date and Time field it is now translated to a full DateTime value.  The 3 fields in the screenshot represent the 3 different possibilities when retrieving Date time cells from Excel.

• “Excel time” is a cell formatted as Time only so the time is reported accurately but the date defaults to 12/30/1899. See the note above for an explanation of why this is the zero date.
• “Excel Date” is a cell formatted as Date only so the date reads normally, but the time defaults to midnight in UTC.
• “Power Apps” is a cell formatted using a custom Date Time format in excel of “m/d/yyy h:mm”.

ISO 8601 Date Time Format Explained

ISO 8601  is an international standard used to represent date and time related data in an format that can be used to transfer it between applications. It is maintained by the Geneva-based International Organization for Standardization (ISO) and was first published in 1988. The purpose of this standard is to provide an unambiguous and well-defined method of representing dates and times, so as to avoid misinterpretation of numeric representations of dates and times, particularly when data is transferred between countries with different conventions for writing numeric dates and times. The combined Time and Date use the following pattern “YYYY-MM-DDTHH:MM:SS:xxxZ”

• YYYY is the 4 digit year to avoid a year 2000 issue
• MM is the 2 digit month
• DD is the 2 digit day
• T denotes the seperation of the Date portion from the Time portion
• HH is the 2 digit hour in 24 hours 0-23
• MM is the 2 digit minute 0-59
• SS is the 2 digit second 0-59
• xxx is the fractional seconds
• Z specifies that the Time/Date is in the UTC time zone

 

What this means going forward

The good news is that this means you don't have to use a long formula to get the datetime field into a date format.  The bad news is that you no longer get a number that is easy to use in calculations.  Here are some simple formulas and actions you can use to work with the new ISO 8601 formats in Power Automate.

Converting ISO8601 to a Serial Date

This first formula will be useful if you need the datetime from Excel as an actual Serial Date value.  Let’s look at the formula working from the inside out.

div(add(div(float(ticks(‘ExcelDateField’)),10000000),-59926435200),86400)

• ticks(IsoDate) converts the ISO 8601 date to the number of thousandths of a second since 01-01-1900
• float(value) makes sure the result is treated as a floating decimal point number for future computations
• div(value,10000000) there are 10,000,000 thousandths of a second in a minute. So dividing by 10 million gives us the number of seconds since 01-01-1900
• add(value,-59926435200). There are 59,926,435,200 seconds from 01-10-1900 to to 12-30-1899. So subtracting that gives us the number of seconds from 12-30-1899 to the date
• div(value,86400) There are 86,400 seconds in a day.  So dividing by 86,400 gives us the days with the fractional days since 12-30-1899.  This is the same value as the serial date in Excel.

Converting from UTC to local time

One of the problems that arise in the new formatting is that the Serial date in Excel is time zone independent.  There is no time zone implied or stored with the date time. But Power Automate stores all DateTimes as UTC. So when a time independent value is imported it is assumed to be UTC and is displayed that way in the the ISO 8601 format.

This means that dates can shift based on the local time zone if your flow doesn’t account for the time zone shift.  For example, if I enter a date of 2021-01-15 8:00PM in an Excel spreadsheet directly and then try to use it in a local flow to schedule a meeting then the meeting will be scheduled for 2021-01-14 2:00 AM since I live in the Central US time zone which is currently 6 hours behind UTC. This becomes even more complex when you realize that as soon as Daylight Savings time hits I’ll be 7 hours behind. So you have to be very careful to shift the time zone to take those things into account.

There is unfortunately no way to tell a flow to treat the DateTime value in a time zone independent fashion.  There are a number of functions and actions that make it easy to convert from one time zone to another.  But this won’t help in the example above because converting the date from UTC to a local time zone will change the actual date and time.  Instead you have to adjust for the time zone offset yourself before converting to the local time zone. If you know what the time zone offset is you can easily use the following formula to adjust the UTC time to be what it should be when converted to the local time zone.

convertFromUtc(addhours(ExcelDateTime,timezoneoffset, 'o'), 'localtimezone')

Where

• ExcelDateTime is the UTC time imported from Excel
• timezoneoffset is the number of hours difference between the local time zone and UTC. Note: this will vary depending on whether Daylight Savings time is in effect or not.
• localtimezone is the name of the local time you wish to convert to

In my case the timezoneoffset is 5 hours currently because my time zone is 5 hours behind UTC.  So if the DateTime from Excel is 2020-10-01T03:00:00.000Z then the converted value after the formula will be 2020-10-01T03:00:00.0000000 in Central Standard Time.

Conclusion

Hopefully this post has provided the information you need to adapt your Power Automate flows to the new connector settings. In general this change should make working with Dates and Times easier.  But it will break existing flows until provisions are made for the new format.