How to set the Locale of a Network Service (or other System) Account

I had a problem recently with a Sitecore system I was working on. We had 4 machines involved – a development server, a content management server (CM), and two content delivery (CD) servers. The problem was, for the ‘News Search’ page we would get different number of items on the CD servers than the CM or development systems.

2 - Search Filter1 - Search Results Header

CM and Dev would return 8 items for a search of news from 1st April to 30th April. The CDs would return 54 items… Continue reading “How to set the Locale of a Network Service (or other System) Account”

How to set the Locale of a Network Service (or other System) Account

Date Formats in XSL with ddwrt

Previously I’ve blogged about using ddwrt to format dates and datetimes. Well, today, I found myself trying to figure it out again, so here is a reminder. Remember, one of the big advantages of this (in the UK at least, where we are UTC time half the year) is that the DateFormat function accounts for daylight savings (i.e. the difference between GMT and BST)

Add this to the xsl:stylesheet tag at the top:

xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime"

Then you can use something like the following (where item_date is an XSL variable with our date in it):

<xsl:value-of select="ddwrt:FormatDate(string($item_date), 2057, 15)" />

Here the FormatDate function is taking the string of the date, formating it for Great Britain’s locale (2057), and specifying an output format (15). Output formats vary by locale, and not all seem to be valid. I found that when I tried a format of ‘2’, for example, that I got an XSL error.

This is a particularly useful with the Content Query Web Part and the RSS Feed Web Part

Date Formats in XSL with ddwrt

Notes on the Microsoft.SharePoint.WebControls.DateTimeControl

It’s quite nice that this control is available to use in my own pages/web parts, but there are issues:

Here we have in microcosm my problems with Microsoft and date/times – an assumption of the local region, and date time controls that would never be empty, right? I had exactly these same problems when writing an Outlook 2003 to SharePoint 2007 integration too. Makes me a bit annoyed! Especially as we have nullable types! Quit screwing around with DateTimes being structs, make them objects and just return me a bloody null if nothing has been selected!

Notes on the Microsoft.SharePoint.WebControls.DateTimeControl

Search Date Formats…

I keep forgetting this, so a note to myself. Date formats in search results in SharePoint are defined by:

  • For Team Sites, the sites Regional Settings
  • For Collaboration Portals, the Search Center’s Regional Settings

Now, if only I can remember that this time. Often I see systems showing the dates in American date format (don’t get me started on that one!) and this is how you change the displayed format.

Of course, this raises the question of, if you have offices in, say, London and Paris, how do you support the different time zones? Hmm. I’ll have to puzzle over that.

Search Date Formats…

SharePoint Web Services and UTC time fun and games

SharePoint is designed that people can use it from multiple time zones. For example, you might have offices in London, Paris and New York. 0700 hours in New York is not the same time as 0700 in Paris, as many transatlantic telephone calls will attest to. Further, many nations have a ‘summer’ and ‘winter’ time, which seems to have been introduced to annoy dairy farmers and computer programmers.

Thus, SharePoint needs a common way to store these times. It does this using UTC time (Coordinated Universal Time). This is, near enough, GMT, and it’s also called Zulu by pilots, the military, and pedants. 0700Z (the Z represents ‘Zulu’ as in ISO8601) is the same time whether you’re in London or Sydney – just in Sydney, 0700 Zulu is actually in the evening.

Now, you don’t need to worry about this, ‘cos SharePoint is smart enough to translate your local time to UTC when you set a date and time, and to translate it back again when displaying the date to you. Thus, 0700 in New York would be stored as 1100Z in the SharePoint database, and then when you looked at that document’s properties, it would be converted back to 0700. If you looked at the document in, say, London, it would convert 1100Z to 1200. (Well, all this is as happens today – summer/winter time makes things really hairy).

So where am I going with this? I have an application where you fill in a date and time, and submit it to SharePoint. When I get the dates back, though, the time is out by an hour. I’m in the UK and it’s summertime, so my timezone is actually UTC+1; therefore, time conversions seem likely to be the issue. Continue reading “SharePoint Web Services and UTC time fun and games”

SharePoint Web Services and UTC time fun and games

The curious incident of the date column in the night-time

I have been tearing my hair out over a problem with dates and timezones. We have a site column ‘Document Date’ that we are using in our search results page. It only holds a date.

Our client noticed that some dates appeared on the search results page as a day earlier than the value in the lists themselves. For example, the list would show a document date of the 8th of May, but the search results would show the 7th of May. Curious, and the start of a bit of a detective story… Continue reading “The curious incident of the date column in the night-time”

The curious incident of the date column in the night-time

Setting the date format on SharePoint's Central Admin Site

This blew me away – Central Admin in SharePoint 2007 doesn’t have any ‘Regional Settings’. Now, at one level, this might make sense – perhaps you always want it to match, say, the server time, or UTC time. I’m not convinced, but it might make sense.

<rant>What absolutely doesn’t make sense is that the date format it uses is the stupid American ‘mm/dd/yyyy‘ format. Why can the US not accept that the rest of the Gregorian calendar using world (i.e. nearly everywhere else) uses a format of ‘dd/mm/yyyy‘? I mean, isn’t sensible to have a format that offers a gradiated precision of time, rather than dumping the most specific part of it in the middle? Or, if we wanted to accept that central admin will probably only be used by techies, what’s wrong with ‘yyyy-mm-dd‘? Hell, I’d nearly prefer Javascript’s ‘milliseconds since the start of 1970‘ format (nearly, but not quite).

Make the format configurable, or use a standard format like ‘yyyy-mm-dd’. </rant>

I did find some solutions though – I particularly like the way that is transpires that the regional settings page is there, but that you have to enter the URL by hand…

Setting the date format on SharePoint's Central Admin Site