根据current GCC documentation，当我打电话给CTIME时，我应该得到这样的日期：＆＃34; Sat Aug 19 18:13:14 1995＆＃34;。但是，我正在运行GCC 4.8.1（MinGW），我得到的输出是这样的：＆＃34; 08/19/95 18:13:14＆＃34;。我实际上有一个古老版本的GCC（0.5），我测试过，并且在同一台机器上，版本正确地格式化了输出。有没有什么方法可以用文档化的格式制作CTIME输出，还是我不得不编写自己的例程来获取该格式？我需要这种格式，这要归功于我正在处理的一些遗留代码。
答案 0 :(得分：3)
首先，请在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遵循了这个建议，经过测试后发现strftime（）与＆＃34;％c＆＃34;说明符生成的字符串格式与ctime（）相同，只要程序是默认的＆＃34; C＆＃34;语言环境。由于GFortran本身从未设置区域设置（通过调用setlocale），因此这被认为是足够好的。不幸的是，正如您所发现的那样，MSVC libc中的strftime（）不会为％c说明符生成类似ctime（）的字符串。无论如何，现在应该修复，希望这次好。
在任何情况下，使用标准date_and_time比解析ctime的输出要强大得多。
答案 1 :(得分：2)
从您提供的链接：
[...]除非应用程序调用了setlocale，否则输出将处于默认语言环境中，长度为24，形式为“Sat Aug 19 18:13:14 1995”。在其他语言环境中，可能会产生更长的字符串。
因此输出取决于您当前的区域设置（并且您的机器上可能选择的区域设置与编写文档的区域设置不同）。