YvesZHI opened a new issue #1663:
URL: https://github.com/apache/incubator-brpc/issues/1663
**Describe the bug (描述bug)**
我在我的项目中使用了c++11的chrono，为了方便组内不熟悉chrono的同事使用我封装了一层接口（其实我只定义了getCurrentTimePoint，getCurrentTimePoint1和getCurrentTimePoint2是为了debug而专门写的）：
```
template <typename T = std::chrono::milliseconds>
using Clock = std::chrono::time_point<std::chrono::system_clock, T>;
// get current time point
template <typename T = std::chrono::milliseconds>
inline Clock<T> getCurrentTimePoint(int8_t timeZone = 0) {
return std::chrono::time_point_cast<T>(std::chrono::system_clock::now())
+
std::chrono::hours {timezone};
}
std::chrono::time_point<std::chrono::system_clock, std::chrono::seconds>
getCurrentTimePoint1(int8_t timeZone = 0) {
return
std::chrono::time_point_cast<std::chrono::seconds>(std::chrono::system_clock::now())
+ std::chrono::hours {timeZone};
}
std::chrono::time_point<std::chrono::system_clock, std::chrono::seconds>
getCurrentTimePoint2(int8_t timeZone = 0) { // OK
return
std::chrono::time_point_cast<std::chrono::seconds>(std::chrono::system_clock::now())
+ std::chrono::hours {timeZone};
}
```
在一个我开发的业务层的处理brpc请求的接口里，我尝试调用接口getCurrentTimePoint：
```
auto now = getCurrentTimePoint<std::chrono::seconds>();
LOG(INFO) << now.time_since_epoch().count(); // LOG(INFO) 打log到日志文件
```
结果在日志中，我发现now的时间是一个比当前UTC时间早整整1200天的时间。
而后我做了如下测试：
```
auto now = getCurrentTimePoint<std::chrono::seconds>(); // wrong
auto now1 = getCurrentTimePoint1(); // wrong
auto now2 = getCurrentTimePoint2(); // correct
auto now3 =
std::chrono::time_point_cast<std::chrono::seconds>(std::chrono::system_clock::now());
// wrong
auto now4 = std::time(nullptr);
LOG(INFO) << now.time_since_epoch().count() <<
now1.time_since_epoch().count() << now2.time_since_epoch().count() <<
now3.time_since_epoch().count() << now4;
```
结果发现，now和now3是错的，即它们都是一个1200天之前的UTC时间，而now1，now2和now4是对的，即它们都是当前的UTC时间。
最诡异的地方是，getCurrentTimePoint1和getCurrentTimePoint2，除了函数名不一样之外，什么都一样，但返回的结果一个对一个错！
**To Reproduce (复现方法)**
目前只在我的机器上出现。而且，必须是基于brpc框架开发的服务里才会出现。如果我只是简单写个main.cpp的demo，运行的话，上面的所有都是正确的。
因此目前我只能怀疑brpc框架的问题。
**Expected behavior (期望行为)**
上述所有接口均返回当前的UTC时间。
**Versions (各种版本)**
OS: Ubuntu 16.04.4 LTS.
Compiler: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.11)
brpc: brpc v0.9.5
protobuf: 3.0
lscpu:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 32
On-line CPU(s) list: 0-31
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz
Stepping: 4
CPU MHz: 2100.000
BogoMIPS: 4201.35
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 1024K
L3 cache: 11264K
**Additional context/screenshots (更多上下文/截图)**
这个截图和上面的描述不太一样，这是一个我调试中的截图，打印了更多的now，大家可以直观地看下这个问题。
1641355346是正确的值，1537675346是错误的值。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
