Does your SharePoint alerts have the wrong time…?
Over the past few months I have seen numerous reports stating the SharePoint is reporting the inaccurate time in the alerts received by end-users. Reports of this issue are sporadic and nobody seems to have a solid solution for it. I received some of the reports on one of my own blog postings (Getting SharePoint Calendar Reminders in Outlook) regarding this issue.
I think the best way to start attempting to solve this problem is to gather information about the problem. I wrote a little utility that will spit out some information about your regional settings as defined in Windows, SharePoint, and on the alerts themselves. The SharePoint build information is also included in the output.
To run the utility, simply type:
RegionInfo -url <the url of the site with bad alert information>
And the output will look something like this:
Gathering Region Information (5/19/2008 9:23:10 AM) …
System Information
==================
Daylight Savings Time Zone: Pacific Daylight Time
Standard Time Zone: Pacific Standard Time
Universal Time: 5/19/2008 4:23:10 PM
Local Time: 5/19/2008 9:23:10 AM
Offset: -07:00:00
SharePoint Information
======================
Farm Build #: 12.0.0.6300
Web Application Time Zone ID: 13
Root Web
========
Zone ID: 13
Zone Description: (GMT-08:00) Pacific Time (US and Canada)
Universal Time: 5/19/2008 4:23:10 PM
Web
===
Zone ID: 13
Zone Description: (GMT-08:00) Pacific Time (US and Canada)
Universal Time: 5/19/2008 4:23:10 PM
Alert Information
=================
Type Frequency Title
—- ——— —–
All Immediate Calendar
All Immediate System
The follow is a count of all alerts in the
specified web grouped by timezone ID.
Zone Count
—- —–
13 2
You can download the RegionInfo program by using the SkyDrive link below.
http://cid-06457d244696ab3c.skydrive.live.com/browse.aspx/WSS/RegionInfo
I recommend that you post the output of this program to the comments of this blog post so we can start to gather the information in a central place. Maybe we can find a pattern here.
Update – 5/19/2008
I originally built the application with .NET Framework 3.5. I recompiled for .NET Framework 3.0 for those who have not yet gone to .NET Framework 3.5. Thank you to Jereon for bringing it to my attention.
42 Comments »
Leave a comment
Unknown Feed- An error has occurred; the feed is probably down. Try again later.
-
Archives
- October 2009 (1)
- September 2009 (2)
- August 2009 (5)
- July 2009 (2)
- June 2009 (2)
- May 2009 (2)
- April 2009 (1)
- March 2009 (1)
- February 2009 (1)
- January 2009 (3)
- December 2008 (1)
- November 2008 (3)
-
Categories
-
RSS
Entries RSS
Comments RSS
Paul Liebrand's Weblog 
thanks for writing the utility, but it doesn’t work on our servers, getting the below error (we are running .NET 3.0, not 3.5, could that be the problem?):
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or ass
embly ‘System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c56193
4e089’ or one of its dependencies. The system cannot find the file specified.
File name: ‘System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c
561934e089’
at AlertInfo.Program.Main(String[] args)
Good Catch! I just rebuilt it for .NET Framework 3.0. You should be good to go (hopefully).
Just ran it on ours and it seemed to work.(i didn’t think i was using .NET 3.5…)
I had a permissions error at first so I ran it as the account that is running the timer service.
Here is the output…
————————————
Gathering Region Information (5/19/2008 3:45:53 PM) …
System Information
==================
Daylight Savings Time Zone: Central Daylight Time
Standard Time Zone: Central Standard Time
Universal Time: 5/19/2008 8:45:53 PM
Local Time: 5/19/2008 3:45:53 PM
Offset: -05:00:00
SharePoint Information
======================
Farm Build #: 12.0.0.4518
Web Application Time Zone ID: -1
Root Web
========
Zone ID: 11
Zone Description: (GMT-06:00) Central Time (US and Canada)
Universal Time: 5/19/2008 8:45:53 PM
Alert Information
=================
Type Frequency Title
—- ——— —–
None Found
The follow is a count of all alerts in the
specified web grouped by timezone ID.
Zone Count
—- —–
None Found
END
Looks like the web application time zone id is wierd…
I originally noticed the problem on my production server and then reproduced it on my development server. Both “Web Application” time zones are set appropriately now…development wasn’t when I ran the app above.
Here is the output of the development system with the web application time zone set properly and 1 alert set up for my user.
————————————-
Gathering Region Information (5/19/2008 3:59:37 PM) …
System Information
==================
Daylight Savings Time Zone: Central Daylight Time
Standard Time Zone: Central Standard Time
Universal Time: 5/19/2008 8:59:37 PM
Local Time: 5/19/2008 3:59:37 PM
Offset: -05:00:00
SharePoint Information
======================
Farm Build #: 12.0.0.4518
Web Application Time Zone ID: 11
Root Web
========
Zone ID: 11
Zone Description: (GMT-06:00) Central Time (US and Canada)
Universal Time: 5/19/2008 8:59:37 PM
Alert Information
=================
Type Frequency Title
—- ——— —–
None Found
The follow is a count of all alerts in the
specified web grouped by timezone ID.
Zone Count
—- —–
None Found
END
———————————-
It doesn’t appear to see my alert…
Also, here is the alert that I received from sharepoint after adding a calendar item.
———————————-
Title: testing 1 2 3
Start Time: 5/18/2008 7:00 PM
End Time: 5/19/2008 6:59 PM
Description:
All Day Event: Yes
Recurrence: No
Workspace: No
———————————–
I set the event for 5/19/2008 and made it an all day event.
Here is the output when I changed the event to not be an all day event and left the default start time and end time.
——————–
Title: testing 1 2 3
Start Time: 5/19/2008 12:00 AM 5/19/2008 5:00 AM
End Time: 5/19/2008 11:59 PM 5/20/2008 4:59 AM
Description:
All Day Event: Yes No
Recurrence: No
Workspace: No
—————————————–
the first values are supposed to be font “strike-through” the second values above are the new ones.(it shows the correct original value for start/end times on this email alert…not on the initial “add” alert)
Here’s the output when I deleted the event.
———————-
Title: testing 1 2 3
Start Time: 5/19/2008 12:00 AM
End Time: 5/19/2008 11:59 PM
Description:
All Day Event: No
Recurrence: No
Workspace: No
———————-
Make sure you are specifying the full web URL of the site that contains the alerts. The program currently does not enumerate all sites and alerts. For example, if you have a sub-site called Test (http://portal.company.com/Test) then when you run the utility specify “-url http://portal.company.com/Test“. If it still does not find alerts let me know.
OK now it works, thanks for rebuilding it.
When I create an event and check the ‘all day event’ box, I have the time offset problem. But when an event has a set start/end time, the offset problem does not occur.
this is the result from an all day event, first the text from the browser:
Start Time 5/18/2008 12:00 AM
End Time 5/19/2008 11:59 PM
Description all day event
this is what I got in my first alert (time offset by 7 hours):
Start Time: 5/18/2008 5:00 PM
End Time: 5/19/2008 4:59 PM
Description: all day event
after changing the date (leaving it an all day event), this is what I see in the version history (time offset by 7 hours):
2.0 5/19/2008 5:17 PM System Account
Start Time 5/20/2008 5:00 PM
End Time 5/21/2008 4:59 PM
and this is what I get in the alert (after modifying the date, where the date/time in parenthesis is striked out to indicate the previous value):
Start Time: (5/19/2008 12:00 AM) 5/21/2008 12:00 AM Edited
End Time: (5/19/2008 11:59 PM) 5/21/2008 11:59 PM Edited
Description: all day event
strangely enough, the time is now correctly displayed and is not offset by 7 hours.
this is the result from the RegionInfo utility:
System Information
==================
Daylight Savings Time Zone: Pacific Daylight Time
Standard Time Zone: Pacific Standard Time
Universal Time: 5/20/2008 12:17:52 AM
Local Time: 5/19/2008 5:17:52 PM
Offset: -07:00:00
SharePoint Information
======================
Farm Build #: 12.0.0.6219
Web Application Time Zone ID: -1
Root Web
========
Zone ID: 13
Zone Description: (GMT-08:00) Pacific Time (US and Canada)
Universal Time: 5/20/2008 12:17:52 AM
Web
===
Zone ID: 13
Zone Description: (GMT-08:00) Pacific Time (US and Canada)
Universal Time: 5/20/2008 12:17:52 AM
Alert Information
=================
Type Frequency Title
—- ——— —–
All Immediate System
All Immediate Calendar
The follow is a count of all alerts in the
specified web grouped by timezone ID.
Zone Count
—- —–
13 2
Here is the sub site info and it has my alert listed.
—————————-
Gathering Region Information (5/20/2008 7:35:35 AM) …
System Information
==================
Daylight Savings Time Zone: Central Daylight Time
Standard Time Zone: Central Standard Time
Universal Time: 5/20/2008 12:35:35 PM
Local Time: 5/20/2008 7:35:35 AM
Offset: -05:00:00
SharePoint Information
======================
Farm Build #: 12.0.0.4518
Web Application Time Zone ID: 11
Root Web
========
Zone ID: 11
Zone Description: (GMT-06:00) Central Time (US and Canada)
Universal Time: 5/20/2008 12:35:35 PM
Web
===
Zone ID: 11
Zone Description: (GMT-06:00) Central Time (US and Canada)
Universal Time: 5/20/2008 12:35:35 PM
Alert Information
=================
Type Frequency Title
—- ——— —–
All Immediate Calendar
The follow is a count of all alerts in the
specified web grouped by timezone ID.
Zone Count
—- —–
11 1
END
The last post(23 Jan 2008) to this article on msdn seems to indicate some common problems when integrated with Outlook.
His comment about the database storing the “All Day Event” types times as 00 and 23:59 but a specifically timed event(non-all day event) gets the date and time stored in UTC could be hitting pretty close to the mark.
It makes sense that an “All Day Event” could be getting interpreted incorrectly by the alert template for that list since it is simply outputting the start and end times as calculated times based on your current time zone. This would mean that the “All Day Event” flag at entry into the database tells the database to store it as 00 and 23:59 UTC(with the same date) when it should be stored as different dates UTC based on your time zone.
The fact that the email alert templates that are used by sharepoint do NOT interpret an all day event properly when outputting the start and end times points toward a problem with the way they were set up to begin with. If the same problems exist with Outlook integration, then the problem could very well be at the database level in how the event is stored.
Wish I had a resolution that would fix this problem…
oops, here is the article
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2282699&SiteID=1
I have the same behaviour as Kevin is describing: when I uncheck the “all day event” option but leave the times unchanged (12AM-11:59PM), my alert displays the correct old times but the displayed new times are offset by 7 hours. however, they are now offset by +7 hours!!! while the other times where offset by -7 hours! Kevin seems to have the same problem with his 5 hour offset, -5 hours when creating an all day event, +5 hours when unchecking “all day event” but leaving the times at 12:00AM-11:59PM.
the version history shows the correct times.
Start Time: (5/21/2008 12:00 AM) 5/21/2008 7:00 AM Edited
End Time: (5/21/2008 11:59 PM) 5/22/2008 6:59 AM Edited
All Day Event: (Yes) No Edited
(in parenthesis are the old values)
when I change my event again and now set different times (8:00AM-5:05PM), my alert displays the correct information:
Start Time: (5/21/2008 12:00 AM) 5/21/2008 8:00 AM Edited
End Time: (5/21/2008 11:59 PM) 5/21/2008 5:05 PM Edited
All Day Event: No
TO SUMMARIZE:
the problem seems to occur only when you start off with an “all day event”. the initial email will display the times minus the time zone offset hours (it’s really taking the set time and ADDING the offset, which is negative in my case; so the alert email time is not even UTC time but UTC time minus 2x the offset).
when you change the event and uncheck “all day event” but leave the times unchanged (12AM-11:59PM), the alert email shows the correct old times but the new times are now positively offset by time zone offset (so display the UTC time).
if you then change the event again and set the times to something else, the alert email displays the correct old times AND the correct new times.
can you confirm this behaviour?
it would make sense to think that the alert email template assumes the times are stored as UTC time and therefore offsets the times in the email by the time zone. this would explain why the initial “all day event” email displays the times as ‘midnight minus time zone offset hours’. but it doesn’t explain why the alert email after unchecking “all day event” are offset the opposite way (so ‘midnight plus time zone offset hours’)?
I will take a look at the database to see what happens there. unfortunately I don’t think we can fix this problem and it’s not clear if MS is aware of it.
Everything described so far based on the information gathered indicates the the initial email is being adjusted by the timezone offset — ultimately there is some time adjusting issues going on here. I also do not think Microsoft is aware of the problem. I am running on almost the latest version of SharePoint (I think I am 1 or 2 post SP1 hot fixes behind) and have the same problem.
Now if we can just get a few more people to validate the issue we should be able to go to Microsoft with this and attempt to get a fix. It could be anywhere between 9-12 months before you see this get fixed.
I also want to point at that this obviously does not appear to be a configuration issue. The utility proves that all web zone information is setup correctly.
I agree. I also found this MSDN post: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3372656&SiteID=1&mode=1 and I submitted some comments and a link to this blog.
in case anyone is interested in what it looks like in the database, use this query (change tp_listid and tp_ID to something that matches your environment):
select datetime1, datetime2, bit1, tp_iscurrentversion, tp_version from alluserdata
where tp_listid = ’49dc3d86-b77d-4d9c-be4f-687a63451ec5′
and tp_ID = ‘3’
order by tp_modified DESC
Thanks for the query example. I was able to look my alert up with the tp_listid only, found by looking in my ImmedSubscriptions table.(I’m the only person using the development server here so there is only that one alert)
Is ImmedSubscriptions.UserId the same as AllUserData.tp_ID?
I don’t think so. the tp_ID is the ID of the event item and one way of finding this is by opening the event from your list in the web browser; the ID should show up in the address bar as a parameter on the query string (normally the first one).
the easiest way to find the tp_listID is by going into your list settings (again, in the web browser) and clicking on ‘Information management policy settings’; your listid should be the only parameter on the querystring in the address bar.
I haven’t looked at the alerts in the ImmedSub table (yet).
I honestly do not think the problem lies with how the data is stored. I believe the problem lies in the code that the job runs. MS is either a) doubling up on the time zone adjustment, or b) they are unnecessarily adjusting the time zone.
I think there is both a problem with how the times are stored in the database (for the initial creation of an all day event) and with the code that generates the alerts.
I know there is an inconsistency in the way the times are stored in the database: if you create an all day event, the times are stored as 12:00AM – 11:59PM, so as local absolute time, not UTC time. if you then go back to the event and uncheck “all day event” but leave the times at 12AM-11:59PM, a new entry (when versioning is turned on) is made but now the times are stored as UTC time.
it seems strange this to that this is done on purpose, looks like a bug to me. but on top of that the alerts don’t interpret the times correctly either.
That’s hilarious. I will verify jeroen’s comments about what is actually stored in the db. If he is correct, then they will have several things to fix. I wonder if it’s possible to implement our own fix for this in the mean time…like a stored procedure or perhaps some tweaks to their input form templates…(bear in mind, i wouldn’t know where to begin for the input form templates, but I could take a stab at some sort of stored procedure…)
Cheers
I captured the SQL query using the profiler and this is just calling the ‘proc_AddListItem’ stored procedure. this sp doesn’t do anything with the date/time but just inserts it into the table. take a look at the sql that is executed when I create a new all day event: http://cid-a114391ee07d2109.skydrive.live.com/self.aspx/blogposts/sqlsample_to_insert_new_event_item.txt
when I change this item and uncheck “all day event” but leave times unchanged, the sql that is executed now shows the times in UTC format (and querying the table shows this as well).
@Kevin – I am sure Microsoft will fix this issue. However, they will probably claim it has a low business impact and it will land up at the bottom of the bug fix list.
@Jeroen – Interesting… they definitely have some inconsistencies going on.
This exact problem is happening for us with connecting sharepoint calendars to Outlook as well, but only with Outlook 2003. At my site, most users are using 2003, but a few are on 2007. On 2007, the all day events show correctly, but on 2003 they appear to spill over 2 days. If you open the item, it shows the time info as “From 12:00AM to 11:59PM (GMT) Casablanca, Monrovia, Reykjavik”
Hopefully this issue is resolved soon as we are in the middle or rolling this out company-wide, and this feature is going to be used quite often by our users.
Cheers!
Forgot to post my output, here it is below. Also, can someone else try the ‘connect to outlook’ if they have outlook 2003 to see if that bug is also repeatable?
Thanks!!
Gathering Region Information (6/18/2008 4:26:02 PM) …
System Information
==================
Daylight Savings Time Zone: Canada Central Standard Time
Standard Time Zone: Canada Central Standard Time
Universal Time: 6/18/2008 10:26:02 PM
Local Time: 6/18/2008 4:26:02 PM
Offset: -06:00:00
SharePoint Information
======================
Farm Build #: 12.0.0.6219
Web Application Time Zone ID: 36
Root Web
========
Zone ID: 36
Zone Description: (GMT-06:00) Saskatchewan
Universal Time: 6/18/2008 10:26:02 PM
Web
===
Zone ID: 36
Zone Description: (GMT-06:00) Saskatchewan
Universal Time: 6/18/2008 10:26:02 PM
Alert Information
=================
Type Frequency Title
—- ——— —–
All Immediate Calendar
The follow is a count of all alerts in the
specified web grouped by timezone ID.
Zone Count
—- —–
36 1
END
too was having the same problem with the “ALL Day Events” feature when using Outlook 2003 and connecting my Sharepoint calendar to Outlook 2003. When the sharepoint calendar was viewed in Outlook, the time was also off by minus 5 hrs but did display the correct time in the Outlook calendar after the event was exported to Outlook. I also had the problem of existing shared calendars in Outlook 2003 disappearing when I connected the sharepoint calendar to Outlook. It appears all functionality between sharepoint and Outlook 2003 does not work 100 % correctly but does work correctly when using Outlook 2007. In sharepoint you can share tasks with Outlook 2007 but not Outlook 2003.
I loaded Office 2007 on a test pc and and everything worked correctly in regards to connecting sharepoint calendars to Outlook 2007 without existing shared calendars disappearing and also using the All Day Event feature. Times were correctly displayed when viewing the event via the sharepoint calendar in Outlook 2007. I did not test the Alert feature using the All Day Event but would venture to say that Outlook 2007 would probably resolve this issue also since they’re all related.
I’ve just found this thread after spending all morning replicating time stamp issues. In a nutshell, I can show the same issue but with a twist!
If I create a new calendar item which is an all day event over 2 days, everything on screen shows fine e.g.
Title: Add new
Start: 23/08/2008 00:00
End: 24/08/2008 23:59
All Day Event: Yes
I set an alert on this calendar and the initial alert on creation shows:
Title: Add new
Start: 23/08/2008 01:00
End: 25/08/2008 00:59
All Day Event: Yes
If I edit the same item I get the results below:
On screen –
Title: Add new event
Start: 23/08/2008 00:00
End: 24/08/2008 23:59
All Day Event: Yes
Emailed alert –
Title: Add new event
Start: 23/08/2008 00:00
End: 24/08/2008 23:59
All Day Event: Yes
So without even unchecking the all day alert box, I can get the time to “fix” itself. We are having so many problems relating to dates and times and I have changed the regional settings in as many places as I can. I haven’t had a change to download the app and publish my findings but I thought I’d share my experiences!
I’ve recently noticed that my email Alerts display an incorrect Start and End Time if the alert is for the creation of an All Day Event.
If you view the item in the site calendar – the time displays correctly. It’s only the text in the email Alert that it is incorrect.
I have checked all the regional setting at hte user level and at the site level, but no luck yet. Came across this post, would be great if anyone or Microsoft can get a quick fix for this issue.
I can verify the same issue on our system (at -4 hours instead), but don’t have the authority to run the utility on our servers to give the output. In case MS is interested, we use it for scheduling Time Off, and so it really impacts us as the days actually shift.
Affects about 250 users here.
Any resolution to this issue. We use Outlook 2007 and created some recurring events in outlook and copied them to SharePoint within Outlook. We discovered that SharePoint was adding a day onto the occurence. It seemed to be right if we used number of days rather than an end by date.
Also added a one time recurring event from 12:30am to 11:30pm (23 hours) on 10/15/2008. in outlook. In SharePoint it shows as: 10/15/2008 12:30 AM 10/14/2008 11:30 PM which means it does not show.
Sure sounds like a bug to me.
We are experiencing the same issue with alerts being offset incorrectly. Is anyone aware of where MS stands on this? Is there a bug logged of which we can check the status?
I’m experiencing the same offset problems with not only the calendar alerts but for document library alerts as well.
Another problem, probably somehow connected, and, at least for my company – serious business impact…
Try to create a custom Date or Date/Time column in wss3.0 built-in calendar list. Create new event, set start date, end date, Your custom date and check the all-day event checkbox. Edit Your event few times. Every time You edit the event, Your custom date field decreases or increases a day off if it’s a Date field, or an hour off, if it’s Date/Time field. Looks quite messy and i’m not going to believe it’s a feature.
The problem exists only for wss3.0 time zone setting other than Greenwich time. If You are in time zone GMT+ Your custom fields entries decreses, GMT- -> increases.
My configuration:
Windows server 2003 r2
WSS 3.0
WindowsIntDatabase
Tried clean WSS3.0, WSS3.0 +sp1 and WSS3.0+sp1+december update -> same things happen.
I seem to be having the same problem. It only happens on alerts and calendar items can be viewed properly on Outlook 2007. Here are the rusults from my RegionInfo:
Gathering Region Information (3/2/2009 8:53:41 AM) …
System Information
==================
Daylight Savings Time Zone: Central Daylight Time
Standard Time Zone: Central Standard Time
Universal Time: 3/2/2009 2:53:41 PM
Local Time: 3/2/2009 8:53:41 AM
Offset: -06:00:00
SharePoint Information
======================
Farm Build #: 12.0.0.6219
Web Application Time Zone ID: -1
Root Web
========
Zone ID: 11
Zone Description: (GMT-06:00) Central Time (US and Canada)
Universal Time: 3/2/2009 2:53:41 PM
Web
===
Zone ID: 11
Zone Description: (GMT-06:00) Central Time (US and Canada)
Universal Time: 3/2/2009 2:53:41 PM
Alert Information
=================
Type Frequency Title
—- ——— —–
All Immediate Migration Calendar
All Immediate Calendar: OCDD Region 6 – Leesville Residential and Empl
oyee Services (130 users)
All Immediate Calendar: Region 3 CART (6 Users)
All Immediate Calendar: Assumption MHC Region 3 (2 Users)
All Immediate Calendar: OMF Contracts Section – Bienville Bldg
All Immediate Team Discussion: Generic users
All Immediate Team Discussion
The follow is a count of all alerts in the
specified web grouped by timezone ID.
Zone Count
—- —–
11 8
END
See this link.
http://support.microsoft.com/kb/919042
Microsoft will not fix this, but instead recommends upgrading to Outlook 2007.
Adam,
Although that is a good KB article to have around — the problem we are specifically talking about is the “alerts” being generated by SharePoint and being delivered via email. The information within the email itself is off. This post does not refer to calendar items that are sync’d to Outlook calendars.
Thanks,
Paul Liebrand
I think I am experiencing the same bug in a different way. I have a calendar that shows out of office days for telecommuting workers. I was trying to create a DataView to show who was telecommuting ‘today’. But it is off by one day for the Start Time.
To try to isolate the problem, I created a calculated date/time column that was simply =[Start Time]. If I view both columns in a standard view, the Start Time reads 5/08/2009 12:00 AM and the calculated field reads 05/07/2009 8:00 PM.
I have checked my regional settings and the time zone settings on the SharePoint server and both are set to Eastern Time.
If I change the regional settings at the site level to GMT-1 (Azores) they then match up perfectly at 12:00 am.
My suggestion to my boss was to transfer me to the Azores, but he isn’t going for it.
Thank you for the regioninfo utility. We were having a situation where just one subsite was off by 2 hours. You utility helped to point that out. After spending at least a day on this and researching blogs on the web, we finally discovered that the subsite with problem had the wrong time zone selected in its regional settings. I was totally unaware that each site has its own regional settings. Problem solved.
Ok,
Update: Just found another ‘incarnation’ of this problem. If a user copies and all day event from SharePoint into his calendar and then syncs his Windows Mobile 6.1 device to the calendar, it shows incorrect times as above. Odd thing is this doesn’t happen with WM 5.0.
I was ok with having the solution be ‘upgrade to Outlook 2007’, but this new problem isn’t really acceptable.
Is anyone else seeing this behaviour?
Cheers!
In my case, I created a calendar and added Begin and End columns so as to filter by date, and to display dates formatted without time. The values for these are set =[Start Time] and =[End Time], resp. Originally, I was getting the 7 hour differential, then it self resolved. Now, months later, the differential is back; I have added +0.2917 to each to adjust. Now I see that nearly all all-day-events agree with the native reference time fields; but some remain 1 hour off. Events with explicit times are now off by 7. Seems like I should back out my adjustment and pray for another self-correction. ???
This seems to correlate with installation of the August patches from Microsoft, Sunday.