British Summer Time Problem

[Anonymous]

I have a PowerApp and a Flow connected to it, which sends an email to the company with the data pulled from a SharePoint List.

There are a few Date columns in the list, however since we changed to BST (+1Hour) all the dates are now an hour behind (even though the correct date/time shows in the form).

I have read a few posts regarding TimeZoneOffset but I can't seem to apply it to my application.

For simplicity I will focus on one data card called: 

"Event_x0020_Date_x0028_s_x0029__"

The update on this card is:

"MasterDate.SelectedDate + Time(Value(MasterHour.Selected.Value), Value(MasterMinute.Selected.Value), 0)"

On the Flow, the formula used to display the date on an email is:

formatdatetime(item()?['Event_x0020_Date_x0028_s_x0029__'],'dddd dd MMMM yyyy H:mm')

Any help anyone can offer would be greatly appreciated

[v-yamao-msft · Accepted solution]

Hi @Anonymous ,

It is a known issue for PowerApps and Microsoft Flow.

PowerApps will convert date time values to the local value. On PowerApps, when you set the DateTimeZone property of a Date picker control to UTC, it assumes that the input value is in UTC, the control will then display the local value to the user.

In your scenario, let’s say you’ve input date time value of ‘01/05/2019 00:00 UTC’, PowerApps recognizes that your timezone is BST and subtracts 1 hour to show the input value in your local time. The displayed date time value is “30/04/2019 23:00”.

Please consider using function addhours to add 1 hour to the date time value.

More details about addhours, please check it at here:

https://docs.microsoft.com/en-us/azure/logic-apps/workflow-definition-language-functions-reference#addHours

Best regards,

Mabel

[Anonymous]

So are you saying that we should edit our flows every 6 months to remove the BST logic?

What about in a system where the date is not representative of the current time?

The only way I see this being a feasible workaround in flow is if you check the date value is within the range of the timezone offset for the summer time and then add an hour. Which is horrific to implement in flows logic.

SharePoint Workflows run in the SharePoint's locale so it avoids this problem.

For all who have to deal with BST or any other timezone with a shifting summer time I recommend using Bing's Timezone API since it's free. You can then convert to the required timezone; do your date operations and then convert it back.

Hopefully this point will be moot next year when most countries abandon Summer Timezone offsets. I'll be much closer to sanity then.

[Anonymous]

I've found a solution in this expression:

https://docs.microsoft.com/en-us/azure/logic-apps/workflow-definition-language-functions-reference#c...

In your context:

convertFromUtc(item()?['Event_x0020_Date_x0028_s_x0029__'], 'GMT Standard Time', 'dddd dd MMMM yyyy H:mm')

This has worked for me year round, accounting for changes in BST.

[StephenP]

Hi Dan,

What were your findings? Did it work?

Kind Regards,

Steve

[Anonymous]

Hi Steve,

My solution has worked all year round, I'll see if I can edit my previous reply to clarify.

Thanks,
Dan

[StephenP]

Thanks Dan, that's really helpful to know!

Kind Regards,

Steve

[StephenP]

Hello,

This didn't work for me - I think my issue was more related to the API's/applications being used though - I was working with Outlook/Office 365 and Google Calendar. What helped in the end was this:

https://powerusers.microsoft.com/t5/Building-Flows/Google-Calendar-to-365-changing-event-time/m-p/83...

I had to convert from UTC to UTC, I think this is due to Google Calendar utilising BST whereas Outlook is using GMT but must be doing some hidden conversion. I've not yet tested it in the winter so we'll see how that goes then!

Kind Regards,

Steve

[sips1]

Thanks @Anonymous . The convertFromUtc worked for me.

I used:

convertFromUtc(utcNow(), 'GMT Standard Time', 'dd/MM/yyyy hh:mm')

[GuyBoswell]

Hi @v-yamao-msft Mabel

Please don't I am having a go at you - you are being very helpful.  But it just isn't good enough to have a, "known issue"!  MicroSoft need to sort this out.  The work around, addhours, is incredibly complex to use because the date on which UK times changes from GMT to BST is different each year.  Anybody any idea how we get this properly resolved?

Thank you

Guy

[GuyBoswell]

Here, here!  Unfortunately it looks like we are stuck with GMT / BST for now and might be stuck with just BST in the future!!!

[MartinPyman]

I wrote a whole blog post on it!

https://martinpyman.blogspot.com/2022/08/handling-british-summer-time-when.html

Hope it helps someone

[GuyBoswell]

Hi @MartinPyman 

Your blog only shows the outputs, not the formulas, so I am not clear it overcomes the problem.  The problem is you don't know what time zone you are using because it varies through the year.  Your process seems to work for times today but I can't get it to work for times back in the past, that are a mix of BST and GMT, depending on when they occured 

[MartinPyman]

Hey @GuyBoswell - not sure if you read the whole thing but you can use a step called convert time zone.

You will convert from

(UTC) Coordinated Universal time to

(UTC +00:00) Dublin, Edinburgh, Lisbon, London

This example is for SharePoint data only. The data held on SharePoint will be in UTC. If you did any processing to those times before you saved it to SharePoint then the times may be out of sync.