C++ 中将序列日期 (Excel) 转换为年月日的算法

Phi*_*ZXX 5 c++ datetime parsing date c++17

这篇文章提供了一个非常简洁且纯 C++ 的算法,用于将序列日期 (Excel) 转换为其显式的年月日表示形式(以及反之)。为了方便起见,我贴一个压缩版本:

void ExcelSerialDateToDMY(int nSerialDate, int& nDay, int& nMonth, int& nYear)
{
    // Modified Julian to DMY calculation with an addition of 2415019
    int l  = nSerialDate + 68569 + 2415019;
    int n  = int(( 4 * l ) / 146097);
    l      = l - int(( 146097 * n + 3 ) / 4);
    int i  = int(( 4000 * ( l + 1 ) ) / 1461001);
    l      = l - int(( 1461 * i ) / 4) + 31;
    int j  = int(( 80 * l ) / 2447);
    nDay   = l - int(( 2447 * j ) / 80);
    l      = int(j / 11);
    nMonth = j + 2 - ( 12 * l );
    nYear  = 100 * ( n - 49 ) + i + l;
}

int DMYToExcelSerialDate(int nDay, int nMonth, int nYear)
{
    // DMY to Modified Julian calculated with an extra subtraction of 2415019.
    return int(( 1461 * ( nYear + 4800 + int(( nMonth - 14 ) / 12) ) ) / 4) +
           int(( 367 * ( nMonth - 2 - 12 * ( ( nMonth - 14 ) / 12 ) ) ) / 12) -
           int(( 3 * ( int(( nYear + 4900 + int(( nMonth - 14 ) / 12) ) / 100) ) ) / 4) +
           nDay - 2415019 - 32075;
}
Run Code Online (Sandbox Code Playgroud)

例如

 2019-06-22 <--> 43638
 2000-01-28 <--> 36553
 1989-09-21 <--> 32772
Run Code Online (Sandbox Code Playgroud)

上面的帖子是 2002 年的,所以我想知道是否有更好的替代实现。我所说的“更好”是指更快、更短或不那么晦涩难懂。甚至是算法,它可能提供一定量的预先计算(例如,记录所需年份范围内的 1 月 1 日序列日期,例如 1900 到 2200,然后执行快速查找)。

How*_*ant 6

你展示的算法非常好。在我的平台(clang++ -O3)上,它们生成没有分支(管道停顿)的目标代码,也没有访问远处的内存(缓存未命中)。作为一对,有效性范围从 -4800-03-01 到未来数百万年(范围很大)。在这个范围内,他们模拟了公历。

以下是一些非常相似的替代算法。一个区别是,您的纪元为 1900-01-01,而我介绍的纪元为 1970-01-01。然而,通过这些纪元的差异(25569天)来调整纪元是很容易的,如下所示:

constexpr
std::tuple<int, unsigned, unsigned>
civil_from_days(int z) noexcept
{
    static_assert(std::numeric_limits<unsigned>::digits >= 18,
             "This algorithm has not been ported to a 16 bit unsigned integer");
    static_assert(std::numeric_limits<int>::digits >= 20,
             "This algorithm has not been ported to a 16 bit signed integer");
    z += 719468 - 25569;
    const int era = (z >= 0 ? z : z - 146096) / 146097;
    const unsigned doe = static_cast<unsigned>(z - era * 146097);          // [0, 146096]
    const unsigned yoe = (doe - doe/1460 + doe/36524 - doe/146096) / 365;  // [0, 399]
    const int y = static_cast<int>(yoe) + era * 400;
    const unsigned doy = doe - (365*yoe + yoe/4 - yoe/100);                // [0, 365]
    const unsigned mp = (5*doy + 2)/153;                                   // [0, 11]
    const unsigned d = doy - (153*mp+2)/5 + 1;                             // [1, 31]
    const unsigned m = mp + (mp < 10 ? 3 : -9);                            // [1, 12]
    return std::tuple<int, unsigned, unsigned>(y + (m <= 2), m, d);
}

constexpr
int
days_from_civil(int y, unsigned m, unsigned d) noexcept
{
    static_assert(std::numeric_limits<unsigned>::digits >= 18,
             "This algorithm has not been ported to a 16 bit unsigned integer");
    static_assert(std::numeric_limits<int>::digits >= 20,
             "This algorithm has not been ported to a 16 bit signed integer");
    y -= m <= 2;
    const int era = (y >= 0 ? y : y-399) / 400;
    const unsigned yoe = static_cast<unsigned>(y - era * 400);      // [0, 399]
    const unsigned doy = (153*(m + (m > 2 ? -3 : 9)) + 2)/5 + d-1;  // [0, 365]
    const unsigned doe = yoe * 365 + yoe/4 - yoe/100 + doy;         // [0, 146096]
    return era * 146097 + static_cast<int>(doe) - (719468 - 25569);
}
Run Code Online (Sandbox Code Playgroud)

这些算法向前和向后数百万年有效(包括-4800-03-01之前)。尽管这个额外的范围不会给你带来太多好处,因为公历直到 1582 年 10 月 15 日才开始。

我使用我在 macOS 上编译的两对算法clang++ -O3 -S,生成的目标代码稍小(大约 10%)。尽管它们都很小、无分支且无缓存缺失,但试图通过测量性能来验证这种优势将是一项具有挑战性的工作。

我不认为任何一组的可读性优于另一组。然而,对于那些好奇这些算法如何工作的人来说,这对算法确实带来了令人恼火的详尽推导,并进行了单元测试以确保算法在+/-100万年的范围内工作。

通过在两种算法中进行设置,将有效性范围限制为 [2000-03-01, 2400-02-29],可以在上述算法中获得非常小的性能const int era = 5。我还没有测试过这个选项的性能。我预计这样的增益会体现在噪声水平上。

或者,通过不考虑 的负值来限制 [0000-03-01,数百万年] 的范围,可能会带来一些微小的性能优势era

civil_from_days

const int era = z / 146097;
Run Code Online (Sandbox Code Playgroud)

days_from_civil

const int era = y / 400;
Run Code Online (Sandbox Code Playgroud)

  • 精彩的回答,谢谢!感谢提到“令人恼火的详尽推导”帖子。 (2认同)