為什么 TimeSpan 沒有 Years 屬性？

Question

我正在編寫一個轉換器，它獲取一個人的出生日期並以年為單位生成他們的年齡。 我寫了一些看起來像這樣的東西：

public class DateOfBirthToAgeConverter : IValueConverter
{
    public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
    {
        var date = value as DateTime?;
        if (date == null) return null;
        return (DateTime.Now - date).Years;
    }

    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
    {
        throw new NotImplementedException();
    }
}

我發現TimeSpan上沒有由兩個DateTime對象相減產生的Years屬性。 我對此感到有些驚訝。 我在想為什么可能沒有Years 。 我想這可能是因為閏日，但按照這個邏輯，由於夏令時，不應該有Days 。

沒有Months是有道理的，因為沒有標准的月份長度。

我能夠編寫一些不同的代碼來獲得正確的年齡，但我仍然很想知道為什么TimeSpan上沒有Years或Weeks屬性。 有誰知道原因？

Answer 1

TimeSpan僅包含兩個DateTime值之間的差異。 不知道這個TimeSpan在哪一年。這也是它沒有Months屬性的原因。

例子：

TimeSpan.FromDays(60)

那是幾個月？ 1還是2 ？

---

由於沒有標准的月份長度，因此沒有月份是有意義的。

由於閏年，也沒有標准的年份長度。

解決方法：如果您確實想顯示一個近似值，那么執行TimeSpan.TotalDays / 365就可以了。

編輯：但僅用於粗略估計，不適用於生日。 在生日計算中，正如 Henk Holterman 在評論中指出的那樣，閏日將每 4 年累積一次。 看看這里計算生日。

Answer 2

程序員的生活真的很艱難。

一年的長度是可變的。 有些年份有365天，有些年份有366天。 根據日歷，有些年份甚至可能缺天。 如果說文化，那就更難了，因為中國的農歷一年有 13 個月。

月份的長度是可變的，這是眾所周知的。 這也是要知道在其他日歷中情況可能會變得更糟。

由於夏令時，白天的長度是可變的，這不僅取決於文化，還取決於地理。

由於閏秒，小時和分鍾的長度是可變的。

似乎唯一可靠的是一秒的長度。 所以在內部，時間跨度以秒（或毫秒，這是相同的）存儲。

但是時間單位的可變性使得答案“ n秒有多少（年/月/天/小時/分鍾）？” 總是不准確。

這就是為什么開發人員最終會得到一個在實際中有用但不精確的解決方案。 他們只是忽略了夏令時和閏秒。 然而，由於人們幾乎不問年月，所以他們決定不回答這些問題。

Answer 3

反問：沒有參考點，一年有多長？

由於 TimeSpan 沒有固定的時間點，因此無法明確說出未知時間的一年有多長。 在最簡單的情況下，可能是 365 或 366 天。 影響結果的案例要多得多。

Answer 4

我想這可能是因為閏日，但按照這個邏輯，由於夏令時，不應該有天。

你有一個觀點； 減去兩個日期不能理想地處理夏令時。 如果日期是當地時間，您可能會得到意想不到的結果。

夏令時的變化意味着當地時間的差距或重疊，如果您使用日期進行計算，則會被忽略。 因此，如果您想獲得本地時間的兩個DateTime值之間的確切差異，您應該首先將它們轉換為 UTC，因為它具有線性時間：

TimeSpan diff = date1.ToUniversalTime() - date2.ToUniversalTime();

TimeSpan沒有年份的原因是年份的長度不同。 夏令時問題是您如何計算TimeSpan ，可以規避，但沒有可用於規避閏年的“線性年”。

Answer 5

時間跨度只是存儲毫秒數。 如果您有 (1000 * 60 * 60 * 24 * 365.5) 365.5 天的毫秒數，則不可能知道該毫秒數是否跨越一整年和下一年，如果它只是短短一年，或者它是否跨越三年。 與 30.5 天的毫秒數相同，可能跨越第二個月，可能不到一個月，可能跨越三個月。