我的语言环境中是否存在与时间相关的信息的上限? [英] Is There an Upper Bound in my locale for Time Related Information?
问题描述
在标准命名空间中是否存在可以向前设置的定义:
Is there a definition somewhere in the standard namespace that sets forward:
- 一年中的几个月
- 一周中的天数
- 一天中的时间
- 一小时内分钟
- 在一秒钟之内
结构tm 包含的成员变量必须在这些范围内，但是我在任何地方都找不到定义的限制.
The struct tm has contains member variables that must be in these ranges, but I can't find the defined limits anywhere.
我什至不确定是否定义了与传统设置(12/7/24/60/60)不匹配的语言环境.
I'm not even sure if there are locales defined where these wouldn't match the conventional set (12/7/24/60/60).
即使没有其他限制范围的潜在用户，我也想使用标准命名空间中的定义，而不是随意定义自己的定义.
Even if there aren't potential users with other range limits, I'd sure like to use a define from the standard namespace rather than arbitrarily defining my own.
似乎我不是第一个提出这样要求的人: http://david.tribble.com/text/c0xcalendar.html
我注意到在该提案中提到了struct calendarinfo，它确实满足我的需求.
It looks like I'm not the first to ask for such a thing: http://david.tribble.com/text/c0xcalendar.html
I notice in this proposal there is mention of the struct calendarinfo which does exactly what I'm looking for.
看来这是2009年的最后一次更改.我想从那以后什么都没发生?我想这也意味着这些资料对我来说不容易获得吗?
It looks like the last change on this was 2009. I guess nothing's happened since then? I guess that also means this stuff is not readily available to me?
更多信息， boost :: locale :: calendar :: maximum 似乎完全可以满足我的需求.我不能使用Boost，但是我可以肯定，Boost 中的代码是关于如何提出这些限制的事实上的标准.不幸的是，我似乎无法理解maximum的实现.也许这里的其他人知道如何?
More info, boost::locale::calendar::maximum seems to accomplish exactly what I'm looking for. I can't use Boost, but I'm certain that the code in Boost is the defacto standard on how to come up with these limits. Unfortuantely I can't seem to get at the implementation of maximum. Maybe someone else here knows how?
推荐答案
C和C ++标准对除了格里高利历之外的任何日历都一无所知，
The C and C++ standards say absolutely nothing about any calendar except the Gregorian calendar, and not a lot about that one.
1.一年中的月份
1. Months in a year
唯一会发现的是C标准中tm的tm_mon成员旁边的注释:
The only thing you'll find is a comment in the C standard beside the tm_mon member of tm:
int tm_mon; // months since January -- [0, 11]
好吧，几乎只有.您还会在strftime中找到%b和%B指示符，它们与当前语言环境的缩写名称和与tm_mon对应的完整月份名称相对应.
Well, almost only. You'll also find %b and %B specifiers in strftime which correspond to the current locale's abbreviated and full month names corresponding to tm_mon.
2.一周中的天数
2. Days in a week
您已经:
int tm_wday; // days since Sunday -- [0, 6]
和%a，%A表示strftime.
3.一天中的小时数
3. Hours in a day
您已经:
int tm_hour; // hours since midnight -- [0, 23]
还有strftime个说明符，其中一些对当前语言环境敏感.
There's also strftime specifiers, a few of which are sensitive to the current locale.
4.一小时内的分钟数
4. Minutes in an hour
int tm_min; // minutes after the hour -- [0, 59]
在这种情况下，您还可以从新的C ++ 11 <chrono>库中获得一些帮助:
Also in this case you've got some help from the new C++11 <chrono> library:
std::cout << std::chrono::hours{1}/std::chrono::minutes{1} << '\n';
这将可移植(并始终如一)输出60.如果您的编译器支持constexpr，并且您担心效率，则此数量可以是编译时积分常数:
This will portably (and consistently) output 60. If your compiler supports constexpr and you are worried about efficiency, this quantity can be a compile-time integral constant:
constexpr auto minutes_per_hour = std::chrono::hours{1}/std::chrono::minutes{1};
minutes_per_hour的类型保证为带符号整数且至少29位.
The type of minutes_per_hour is guaranteed to be signed integral and at least 29 bits.
5.一分钟之内
5. Seconds in a minute
C规范对此很有趣:
int tm_sec; // seconds after the minutes -- [0, 60]
该范围未记录为[0, 59]，以便允许添加正leap秒.话虽这么说，但我所知道的任何操作系统都无法真正实现leap秒的准确计算.每个人似乎都遵循 Unix时间，该时间跟踪UTC，但忽略了leap秒.当发生a秒时，我知道所有操作系统都将其视为普通时钟校正. Google著名地将其视为在某些窗口上的涂改涂污时间.
The range is not documented as [0, 59] so as to allow for the addition of a positive leap second. That being said, no OS that I'm aware of actually implements an accurate accounting of leap seconds. Everyone appears to follow Unix Time which tracks UTC except ignoring leap seconds. When a leap second occurs, all OS's I'm aware of simply treat it as an ordinary clock correction. Google famously treats it as a smear of corrections over some window of time.
此外，您可以一致且方便地编写:
Additionally you can consistently and portably write:
std::cout << std::chrono::minutes{1}/std::chrono::seconds{1} << '\n';
并获取60.
尽管未由C或C ++标准定义，但每个操作系统似乎都在测量自1970年新年以来的时间(忽略leap秒).在C ++ 11中，可以通过以下方式获得此数量:
While not defined by the C or C++ standards, every OS appears to be measuring time since New Years 1970 (neglecting leap seconds). In C++11 this quantity is available via:
auto tp = std::chrono::system_clock::now();
，其中tp将具有类型std::chrono::system_clock::time_point. time_point具有不确定的精度(双周，秒，飞秒，等等).该精度可以在编译时以编程方式发现.
where tp will have type std::chrono::system_clock::time_point. This time_point has an unspecified precision (fortnights, seconds, femtoseconds, whatever). The precision is programmatically discoverable at compile time.
如果有帮助，请此链接包含可以将tp转换为年份的代码/月/天小时:分钟:秒，甚至是几分之一秒(反之亦然).哦，如果您想要的话，还可以选择星期几(以及其他一些日历技巧).该公共领域代码取决于1970年新年的非标准，但实际上是便携式的时代.如果需要，可以很容易地将其用于其他时代.
In case it is helpful, this link contains code which can translate tp into year/month/day hour:minute:second and even fractions of a second (and vice-versa). Oh, day-of-week if you want it too (and several other calendrical tricks). This public domain code depends on the non-standard but de-facto portable epoch of New Years 1970. It could easily be adopted to other epochs if the need ever arises.
这篇关于我的语言环境中是否存在与时间相关的信息的上限?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
