We have a Visual Studio workflow that I built with VS2013 and running on SharePoint 2013 (it is a SP2013 workflow).
The workflow is an application for leave, and after it had been in use for a few months, our head of HR asked me to have the workflow automatically calculate the number of leave days needed for a given leave.

After much googling, head-scratching, and cursing, I figured the fastest way to get this to work was writing a custom activity in C#. Which, to my surprise, has worked a lot better than I expected.

The activity takes into account that some employees only work four days as week, and it queries the user's Active Directory account to figure out what federal state she or he lives in - we're located in Germany, and while most holidays are federal, a few are holidays only in select states. So to find out if a given week day is a leave day, we need to find out what state the user lives in, and then figure out if this day is a holidy in that state.

Fortunately I found C# code that, given a date and a state, can say if that day is a holiday in that state, and integrating it into my custom activity worked quite smoothly, too.

All was well (well, mostly) until users started noticing that the number of leave days required for a given period did not match the number they had calculated manually beforehand. Obviously, the activity had a bug of some sort. I added a little code to write a log, so I can see, day by day, if my activity thinks that day is a holiday or not.

I was quite dismayed to discover that for a number of holidays, my code said they were regular work days. I wrote a simple command line application that referenced my custom activity DLL directly, parsed two dates from the command line, and using my activity code, calculates the number of leave days needed for that period, again logging day by day what the result of the check was.

This time I was not so much dismayed as confused. Baffled, really. Because the command line application I had written gave correct results every single time I checked.

I suspected some sort of region setting, but after careful study, I can honestly say that whatever environment the code runs in does not influence the way it checks for holidays. The part that checks if a given day is a holiday has most holidays defined in relation to the Easter weekend, which again is defined by the beginning of spring and the lunar cycle. (The other holidays are fixed, except for one or two oddballs that are defined as "last Thursday in November" or something like that.)

So how can this be? How can the fact my code is running as part of a SharePoint workflow affect the results it is giving? Has anyone ever run into a problem like this?

Thank you very much for any insights you might be able to share with me, Benjamin

  • must be the c# code that you found, did you test/check every federal state? Also, I'd try to test pulling the several users with their federal state in your testing--is it feasible the federal state in AD is wrong for some users?
    – Mike
    Commented Apr 4, 2016 at 12:53
  • The bug was first discovered when somebody wanted to take a vacation over the weeks around the Easter weekend and the code claimed that Good Friday and Easter Monday were workdays, when both days are federal holidays in Germany, so I don't think the state plays into this, at least not exclusively. We checked the AD accounts, and the field for the federal state is set correctly for all users. Also, the test gives correct results when called from my command line application.
    – krylon
    Commented Apr 4, 2016 at 13:06
  • Can you write modify the code to fix the bug? Check to see if it's Easter weekend and return the holiday equals true instead of false? Or is the bug more than that?
    – Mike
    Commented Apr 4, 2016 at 13:07

1 Answer 1


After procrastinating like a champ for about a year, I recently was forced to look into the question again, and this time I found the cause of my problems right away: It was a local time vs. UTC problem.

Inside the SharePoint workflow, retrieving datetime values from a list item returns them in UTC, but we are located in Germany (UTC+0100 in winter, UTC+0200 in summer). So when a user enters, say, April 10 2017 - April 21 2017, what the workflow sees is April 9 2017, 22:00 to April 20 2017, 22:00.

Not having checked for that, all the days in my holiday checker were off by one.

After facepalming myself good and hard for a prolonged period, I converted the datetime values back to local time in my custom activity, which now gives correct results.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.