>>>>>>>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.

A SWAG - could you be running into some issue with Standard vs. Daylight Savings time? For example, Windows 2000 and NT still think it's Standard time. Some routers and other equipment also don't support the "new" North American switch dates (i.e. March instead of April).