Fortran中CTIME输出的格式(Format of CTIME output in Fortran)

Fortran中CTIME输出的格式(Format of CTIME output in Fortran)

根据目前的GCC文件 ，当我打电话给CTIME时，我应该得到这样的日期：“Sat Aug 19 18:13:14 1995”。 但是，我正在运行GCC 4.8.1（MinGW），我得到的输出是这样的：“08/19/95 18:13:14”。 我实际上有一个古老版本的GCC（0.5），我测试过，并且在同一台机器上版本正确地格式化输出。 有没有什么方法可以用文档化的格式制作CTIME输出，还是我不得不编写自己的例程来获取该格式？ 由于我正在处理的一些遗留代码，我需要这种格式。

According to the current GCC documentation, when I call CTIME I should get a date formatted like this: "Sat Aug 19 18:13:14 1995". However, I'm running GCC 4.8.1 (MinGW) and the output I get is like this: "08/19/95 18:13:14". I actually have an ancient version of GCC (0.5) that I tested, and on the same machine that version formats the output correctly. Is there some way I can make CTIME output in the documented format, or am I stuck writing my own routine to get that format? I need that format thanks to some legacy code I'm dealing with.

最满意答案

首先，请通过https://gcc.gnu.org/bugzilla将GFortran错误发布到GCC bugzilla。 无法保证发布到stackoverflow的错误报告不会在噪音中丢失。 FWIW，我在https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61310上提交了这个错误。

对于某些背景，GFortran的这种变化是由于努力摆脱线程不安全的C库函数，如ctime（）。 POSIX提供了一个名为ctime_r（）的线程安全变体，它遇到了许多问题，例如，实际上，不同的接口（一些商业unix支持基于POSIX标准草案的函数，其中ctime_r具有不同的参数），运行等错误超过26个字节，规范说应该足够了，依此类推。 最后，POSIX 2008放弃并将ctime_r标记为过时，并建议使用strftime（）代替。 所以GFortran遵循这个建议，在测试后发现带有“％c”说明符的strftime（）生成的字符串格式与ctime（）相同，只要程序处于默认的“C”语言环境中。 由于GFortran本身从未设置区域设置（通过调用setlocale），因此这被认为是足够好的。 不幸的是，正如您所发现的那样，MSVC libc中的strftime（）不会为％c说明符生成类似ctime（）的字符串。 无论如何，现在应该修复，希望这次好。

在任何情况下，使用标准date_and_time比解析ctime的输出要强大得多。

First, please post GFortran bugs to the GCC bugzilla at https://gcc.gnu.org/bugzilla . There is no guarantee that bug reports posted to stackoverflow don't get lost in the noise. FWIW, I filed this bug at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61310 .

For some background, this change in GFortran was due to an effort to get rid of thread-unsafe C library functions such as ctime(). POSIX provides a thread-safe variant called ctime_r(), which suffers from a number of issues such as, actually, different interfaces (some commercial unixes support functions based on drafts of the POSIX standard, where ctime_r has different parameters), bugs like running past the 26 bytes the spec says should be enough, and so on. In the end, POSIX 2008 gave up and marked ctime_r as obsolescent and recommended the use of strftime() instead. So GFortran followed this recommendation, after testing revealed that strftime() with the "%c" specifier generated strings in the same format as ctime(), as long as the program is in the default "C" locale. As GFortran itself never sets the locale (by calling setlocale), this was thus seen as good enough. Unfortunately, as you have found out, strftime() in MSVC libc doesn't generate a ctime()-like string for the %c specifier. Anyway, this should be fixed now, hopefully for good this time.

In any case, using the standard date_and_time would be much more robust than parsing the output of ctime.