_utime() sometimes fails to set the correct file times in Visual C++ 2013 - by Steve Hay

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 811534 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 12/13/2013 9:10:48 AM
Access Restriction Public


Calling the _utime() function to set the specified file access and modification times and then calling the _stat() function to retrieve those times can yield different times than were specified.

Specifically, the times returned by _stat() can be one hour different to the times passed to _utime() depending on Daylight Saving Time (DST) values. The roundtrip fails for dates and times with the opposite DST value to the computer's current date and time. This was not the case in previous versions of Visual C++.
Sign in to post a comment.
Posted by James [MSFT] on 1/6/2014 at 10:59 PM

Thank you for reporting this issue. This is indeed a bug in the C Runtime (CRT), but it is a longstanding bug; it’s just been made more obvious by recent changes. There are some inconsistencies in the handling of daylight savings time among several families of functions in the CRT, including _stat, fstat, _utime, and the 64-bit and wide string versions thereof. Prior to Visual Studio 2013, all of these functions had a subtle daylight savings time bug: during daylight time, they incorrectly adjusted standard time times as if they were in daylight time. It appears that this went unnoticed (and unreported) for many years because while the implementations were incorrect, they were all consistent.

In Visual Studio 2013, we fixed the _stat family of functions, but not the _utime or fstat families of functions. The issue is much more noticeable now that the functions produce inconsistent results.

We have fixed this in the CRT for the next major release of Visual Studio; we do not plan to retroactively fix the bug in already-released versions of the CRT (e.g., Visual Studio 2013). If you are blocked by this issue, the best possible workaround that I can recommend would be to eschew these CRT functions and call the Windows API functions directly.

Visual Studio includes the source code for the CRT, so you can use that to find how these functions are implemented in the CRT. The sources are installed by default into the “C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\crt\src” directory; if you customized your Visual Studio installation, they may be located somewhere else. The _utime functions are defined in utime.c and utime64.c; the fstat functions are defined in fstat.c and fstat64.c.

The CRT source code includes the “correct” implementation, which is used for the Windows Store apps CRT (msvcr120_app.dll), but not for the desktop apps CRT (msvcr120.dll and libcmt.lib). In the source code, there are blocks that are #ifdef’ed to be compiled when _CRT_APP is defined; these blocks, which use SystemTimeToTzSpecificLocalTime, are correct. The other blocks, which do not use this function, are incorrect. It should be fairly straightforward to piece together the correct implementation by using the CRT sources as a reference and using the _CRT_APP parts of the code.

Concerning portability, my recommendation would be to write a small wrapper function that has conditionally-compiled logic for each platform that you target. This way, the platform-specific logic is encapsulated in one place, rather than spread across your project at each call site.

Please feel free to contact me if you have any further questions.


James McNellis
Visual C++ Libraries
Posted by Macy [MSFT] on 12/15/2013 at 11:47 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Macy [MSFT] on 12/13/2013 at 9:50 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)