[英]VMS timestamp to POSIX time_t — Boost.DateTime bug?
假設轉換產生有效的time_t
,我如何編寫一個C ++函數,該函數采用代表VMS時間戳的long long
值並返回相應的time_t
值? (如果有任何區別,我將在商用CentOS服務器上解析通過網絡發送的二進制數據。)
我看了一個標題為“為什么是1858年11月17日星期三,VAX / VMS的基准時間”的文檔,但我認為如果不使用我沒有的實際數據進行測試,就無法編寫正確的實現。不幸的是,現在手。
如果我沒記錯的話,應該是以下形式的簡單算術:
time_t vmsTimeToTimeT(long long v) {
return v/10'000'000 - OFFSET;
}
有人可以告訴我將OFFSET
值設置為多少嗎?
我擔心的事情:
我試圖在Boost.DateTime的幫助下自己計算它,只是得到一個神秘的負值...
int main() {
boost::posix_time::ptime x(
boost::gregorian::date(1858, boost::gregorian::Nov, 17),
boost::posix_time::time_duration(0, 0, 0) );
boost::posix_time::ptime y(
boost::gregorian::date(1970, boost::gregorian::Jan, 1),
boost::posix_time::time_duration(0, 0, 0) );
std::cout << (y - x).total_seconds() << std::endl;
std::cout << (y > x ? "y is after x" : "y is before x") << std::endl;
}
-788250496
y在x之后
我使用Boost 1.60 :
當前的實現支持1400年1月1日到9999年12月31日之間的日期。
廢話, sizeof(total_seconds())
為4,盡管文檔說了什么
所以我得到了3506716800
auto diff = y - x;
std::cout << diff.ticks() / diff.ticks_per_second() << std::endl;
哪個看起來不太錯,但是...誰能保證這是真的?
哇,你們使圖書館和所有工作看起來都如此困難。 因此,您在1858年11月17日進行了閱讀,發現VMS從該日期起將時間存儲為100nS“舊塊”。 對?
Unix時間是自1970年1月1日以來的秒(或微秒)。 對?
因此,您所需要做的就是從報告的OpenVMS時間ad除以10,000,000(秒)或10(微秒),減去1970年1月1日的OpenVMS時間值“偏移”。 您只需使用簡單的OpenVMS程序即可找到該值。 下面我什至沒有使用專用程序,只是使用了運行隨機可執行程序的OpenVMS交互式調試器:
$ run tmp/debug
DBG> set rad hex
DBG> dep/date 10000 = "01-JAN-1970 00:00:00" ! Local time
DBG> examin/quad 10000
TMP\main: 007C95674C3DA5C0
DBG> examin/quad/dec 10000
TMP\main: 35067168005400000
因此,在十六進制和十進制中都有偏移量,可以根據需要使用。
在最簡單的形式中,您將輸入的OpenVMS時間預除以10,000,000,然后減去3506716800(十進制)以得到Epoch秒。 確保保持數學,包括減法到long-long int
海恩。
據此: https : //www.timeanddate.com/date/durationresult.html?d1=17&m1=11&y1=1858&d2=1&m2=jan&y2=1970
您需要40587天乘以86400秒,將3506716800用作計算的偏移量。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.