Inconsistent time zone in results from Web Service

I have a web service for a production application that is returning different results to different clients for the same inbound request.

I discovered this by configuring my clients to dump the raw WCF messages to trace files, which I then compared.

For one cli开发者_如何学编程ent machine, the response includes date/times targeted at time zone +13:00 - aka NZDT (New Zealand Daylight Time) (see the ObservedDate element):

<b:ObservationDTO>
    <b:mVersionNumber>0</b:mVersionNumber>
    <b:mBoolValue i:nil="true"></b:mBoolValue>
    <b:mDateValue i:nil="true"></b:mDateValue>
    <b:mIsNull>true</b:mIsNull>
    <b:mNumericValue i:nil="true"></b:mNumericValue>
    <b:mObservationID>0</b:mObservationID>
    <b:mObservedDate>2005-09-30T00:00:00+13:00</b:mObservedDate>
    <b:mTextValue i:nil="true"></b:mTextValue>
</b:ObservationDTO>

For another client machine, the response includes date/times targeted at time zone +12:00 - aka NZST (New Zealand Standard Time) (see the ObservedDate element):

<b:ObservationDTO>
    <b:mVersionNumber>0</b:mVersionNumber>
    <b:mBoolValue i:nil="true"></b:mBoolValue>
    <b:mDateValue i:nil="true"></b:mDateValue>
    <b:mIsNull>true</b:mIsNull>
    <b:mNumericValue i:nil="true"></b:mNumericValue>
    <b:mObservationID>0</b:mObservationID>
    <b:mObservedDate>2005-09-29T23:00:00+12:00</b:mObservedDate>
    <b:mTextValue i:nil="true"></b:mTextValue>
</b:ObservationDTO>

Trouble is, the client isn't picking up on the time zone information included and is therefore showing (for this example) 29 September 2005, 11:00pm to the user.

I've double checked, and all the machines involved (both clients, application server and web server) are all correctly configured to NZST:

Tracing through the WCF messages between client and server, the only other differences I've seen are:

• <TimeCreated> - when the message was created
• <Execution> - the source process
• <Computer> - name of the client computer
• <MessageLogTraceRecord> - WCF Message timestamp?
• <MessageID> - GUID for the message

These five elements are different on each message - otherwise the message streams are identical, except for the date/times coming through as noted above.

To summarize:

• Both tests run against the same application server (and, therefore, the same database)
• The same request is being made by both client PCs
• The response to the request has some (around 20%) observations targeted at the wrong time zone
• All the machines are configured to timezone +1200 (NZST).

I figure that there must be a patch or something different between the machines, but after 8 hours of searching, I've yet to find it. Thanks for your time.

Update

Does the "wrong" client consistently get the wrong value for the same entry, or does it vary between calls? Does it always happen the same way round?

Each client is quite consistent from call to call.

The sequence of web service calls results in 26784 distinct time series observations. Both clients get the same number of results, but differ in the time stamps associated with the values. For one client, all 26784 values are midnight aligned; for the other, 5630 of the values (21%) are offset 1 hour earlier than they should be. Not all examples of a specific date/time will be offset: for example, of 992 records that should have timestamp 31/3/2010, 448 instead have 30/3/2010 11pm,

If the requests are absolutely identical, it I can't see how it can really be explained by any difference at the client side.

I'm wondering if there is any "out of band" communication not shown in the WCF message tracing. Wild speculation: we're using "WindowsAuthenticationBasicHttpBinding", so I was wondering if WCF queried AD for locale information or something.

Also, why are the clients ignoring the time zone

We're not knowingly ignoring the time zone, it just seems to be happening. We have DTOs with DateTime properties being serialized across the wire from the server to the client and then reassembled. For convenience, we're sharing the same DTO assembly both server and client side, so I'd (perhaps naiively) expect the Date Time to round trip intact.

The local IT guys managed to identify the answer:

The client PC that was showing "wrong" information (timestamps at 11pm) was missing hotfix KB981793 - a cumulative patch for time zone rules.

Not what I expected at all - but installing that hotfix has fixed the problem on every machine we've tested.