Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

On Office 365,

We have a couple of DateTime managed properties, an ExpiryDate and a Article Start Date, in order to show/hide content from the news section. We are seeing an issue where the query : ArticleStartDate>={Today} uses the UTC date for {Today}. I had thought SharePoint will respect the user’s and sites regional settings for the query of a datetime managed property. But this doesn’t appear to be the case?

For example in Australia right now it is 9/04/2014. But the Today variable is 8/4/2014.

This effectively breaks all date range queries!

Any one come across this previously or have a workaround?

share|improve this question
    
Did you ever find a solution to this issue? –  Nick Larter Aug 27 '14 at 7:43
    
I'm stuck with the same issue.. Did you ever find solution for this issue ? –  ravi kumar mvs Feb 9 at 15:04

2 Answers 2

Are the users setting their local time zone? I can't remember off the top of my head, but the time will default to the Web Application time unless they override this and set their local on their own profile. Let me know and I can try a test.

share|improve this answer

Here you can see how SharePoint is looking up the value for "Today"

    private static string GetTodayValue(string token, IReadOnlyPropertyCollection queryProperties)
{
  string parameterNameFromToken = QueryTemplateHelper.GetParameterNameFromToken(token);
  DateTime dateTime = DateTime.Now;
  if (queryProperties != null && queryProperties.ContainsKey(parameterNameFromToken))
  {
    object obj = queryProperties[parameterNameFromToken];
    if (obj is DateTime)
      dateTime = (DateTime) obj;
    else if (obj is string)
      dateTime = DateTime.Parse((string) obj, (IFormatProvider) CultureInfo.InvariantCulture);
  }
  char[] chArray = new char[4]
  {
    '[',
    ']',
    '{',
    '}'
  };
  token = token.Trim(chArray).Trim();
  string s = token.Substring(5);
  int result = 0;
  if (int.TryParse(s, out result))
    return dateTime.AddDays((double) result).ToString("yyyy-MM-dd", (IFormatProvider) CultureInfo.InvariantCulture);
  return dateTime.ToString("yyyy-MM-dd", (IFormatProvider) CultureInfo.InvariantCulture);
}

As you can see, they do nothing else (besides some minor sideways) than taking DateTime.Now and writing the Date-Portion as string to the query.

Having in mind that SharePoint stores (and finds) all Dates in UTC, the fact that "Today" is replaced by DateTime.Now´s Date makes using it totally worthless. In my opinion the code should be something like DateTime.Today.ToUniversalTime.ToString("yyyy-MM-dd"). And even that would work only for date-only fields. If they Metadata should also respect Time for the user, the "Today" replacement would have to respect overlapping of days (e.g. 11.05.2015 23:00:00 - 12.05.2015 23:00:00). However in current implementation in most cases it would deliver wrong (or not as expected) results, as long as you are not using UTC0 g.

For example: If I set a Date-Metadata for today, 12.05.2015. As we do have UTC+1, SharePoint stores the date for 11.05.2015 23:00:00. If I do a search with the "Today" Option, I wont find it, because today searches for 12.5.2015.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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