System.DateTime
对象有AddYears(), AddMonths(), AddDays(), AddSeconds()
等的方法
我注意到没有AddWeeks()
。为什么会这样?
另外,我的要求是获得52周前的价格值。我知道这相当于1年,但他们说的是52周。
我也可以这样做吗?
yearOldPrice = _priceService.GetPriceForDate(price.Date.AddYears(-1));
yearOldPrice = _priceService.GetPriceForDate(price.Date.AddDays(-7 * 52));
我假定.AddDays(-7 * 52)
和.AddWeeks(-52)
相同,因为一周有7天
正如你在你的问题中所指出的,不像年和月,每周总是有7天(在我的日历上,无论如何),所以当你需要做的只是adddays (weeks * 7)时,拥有一个AddWeeks方法几乎没有什么好处。尽管你不得不质疑当他们有AddMinutes和AddHours的逻辑!该死的他们和他们的前后矛盾!
如果你真的不喜欢。addweeks,你可以为它创建一个扩展方法:
public static class DateTimeExtensions
{
public static DateTime AddWeeks(this DateTime dateTime, int numberOfWeeks)
{
return dateTime.AddDays(numberOfWeeks * 7);
}
}
正如其他人所指出的,一年不是52周。
抽象Calendar
类实现了您所追求的方法,您可以使用区域设置的日历,或者创建实现它的类的对象:
DateTime dt = CultureInfo.InvariantCulture.Calendar.AddWeeks(datetime, weeks);
GregorianCalendar gc = new GregorianCalendar();
DateTime dt = gc.AddWeeks(datetime, weeks);
最终我希望AddWeeks的缺失纯粹是为了避免大量的方法。也许可以添加一个扩展方法:
public static DateTime AddWeeks(this DateTime from, int count) {
return from.AddDays(7 * count);
}
我认为这是因为周数有多种定义,即
ISO对周数的定义(https://en.wikipedia.org/wiki/ISO_week_date)不同于北美对周数的定义,也不同于其他文化。
为什么上面的解释对我们的上下文很重要(为什么不使用'AddWeeks()')
第一周的开始或52/53周的结束在不同的格式/文化中是不同的,所以当我们跨越边界(即年初或年底)添加/减去时,需要额外的信息来确定给定周数的确切日期(他们是否遵循ISO或本地文化格式,周一是开始日还是周日等),这使得该函数变得复杂。我想正是由于这个原因,他们才把周号留给我们来计算。
如果你真的喜欢添加周,如果你不关心周#的定义,那么是的,上面提出的解决方案由Steve Morgan是足够聪明的。
yearOldPrice = _priceService.GetPriceForDate(price.Date.AddDays(-7 * 52);
就是你想要的。请注意,添加一年和添加52周是不同的。
如果你真的需要,你可以创建一个扩展方法:
public static class DateTimeExtensions
{
public static DateTime AddWeeks(this DateTime DT, int Weeks)
{
return DT.AddDays(Weeks * 7);
}
}
这将略有不同。减去52周等于减去364天,而一年等于365(闰年等于366)。
可能没有AddWeeks()
,因为AddDays(-7 * numWeeks)
很容易减去周。
正如@Craig所说:在Powershell中,你可以这样解决:
[int]$WeeksAgo = 52
(Get-Date).AddDays(-7 * $WeeksAgo)
这是一样的,因为周= 7天。AddDays(-7 * 52) == .AddWeeks(-52))
但52周不是一年。AddDays(-7 * 52) != .AddYears(-1))
如果他们是具体的关于52周,那么我会使用-7 * 52,因为一周总是有7天。当存在额外的一天时,使用。addyear将考虑闰年。