>>>>>>This app has been running for several years on Win 7 machines with no problems.
>>>>>>On a new Win 8 machine DateTime.Now.Date returns 2014-03-21:23:00 when it should return 2014-03-22.
>>>>>>The time on the machine is OK and the time zone is correct.
>>>>>>It consistently places the date one hour before midnight on the prior day.
>>>>>>Code works fine on other Win 8 machines.
>>>>>>Any suggestions?
>>>>>
>>>>>You've shown two different formats (neither of which include seconds). How are you viewing these values and what *exactly* are you seeing ?
>>>>>Also they look more like SQL datetime values than .NET (unless you're using something like DateTime.Now.Date.ToString("u",new CultureInfo("en-US"));)
>>>>>
>>>>>If they are .Net then what is currentculture and what do DateTime.Today, DateTimeUtcNow.Date and DateTime.Now.Kind show ?
>>>>
>>>>Viv.
>>>>I ran the tests you mentioned and all of them showed what I'd expect.
>>>>The plot became a lot soupier and more interesting as more facts unfolded.
>>>>The data in question is collected on machine A and stored in a SQL Server table.
>>>>Later, it's exported from a typed dataset to an xml file.
>>>>That xml file is later imported into a SQL Server table on machine B.
>>>>The problem first showed up in a datetime column in a SQL table on machine B.
>>>>I assumed that the data was bad in the table on machine A, hence my post.
>>>>I got a hold of the source machine today and on inspection, the data is OK in the SQL table on machine A.
>>>>Ergo .. something must be happening with the XML.
>>>>I discovered that the writexml method of a dataset might mess up a datetime column by adding some extraneous data and there is a method that can prevent that.
>>>>Before filling the dataset that will fire the method, one can do this:
>>>>mydataset.mydatatable.mycolumn.DateTimeMode = DataSetDateTime.Unspecified;
>>>>and it removes some troublesome things from the output generated by the writexml method for the datetime column.
>>>>
>>>>It looks like a good suspect.
>>>
>>>Looks likely - the DataSetDateTime default is UnspecifiedLocal
>>>
>>>>This is particularly nasty because it only fails at certain times of the day so we won't know for a while whether it worked.
>>>
>>>Does the SQL column record a time portion or is it always 00:00:00 ?
>>>Seems to me that the serialization would be subtracting one hour from *all* datetimes but the date portion would only change for rows where the time was between 00:00:00 and 00:59:59 (give or take a second :-})
>>
>>As far as I can see, the source SQL column is always 00:00:00 but the target SQL column winds up with 23:00:00 and a decremented date.
>
>Sounds like something else going on (as well as the DataSetDateTime setting) - if all rows have the time set to 00:00:00 then, AFAICS, the result of the operation should be the same for all - there is no 'certain times of the day' ?

Yes.
I think that I'm missing some key facts.
I went back and looked at the source columns.. the times are all zeroes.. for sure.
I'm trying to set up a more controlled test environment.. not too easy at long range and odd hours .. but that's what it will take, I think.