Why is there no DateTime.AddWeeks(), and how can I get a DateTime object for 52 weeks ago?

The System.DateTime object has methods to AddYears(), AddMonths(), AddDays(), AddSeconds(), etc.

I've noticed that there is no AddWeeks()开发者_如何学Go. Why is this?

Also, my requirement is to get a price value from 52 weeks ago. I know this equates to 1 year, but they were specific about 52 weeks.

Would it be the same for me to do:

yearOldPrice = _priceService.GetPriceForDate(price.Date.AddYears(-1));

as

yearOldPrice = _priceService.GetPriceForDate(price.Date.AddDays(-7 * 52));

I ask on the presumption that .AddDays(-7 * 52) is the same as .AddWeeks(-52), 'cause there's 7 days in a week.

As you've noted in your question, unlike Years and Months, there are always exactly 7 days per week (on my calendar, anyway), so there's very little to be gained by having an AddWeeks method when all you need to do is .AddDays(weeks * 7). Though you have to question the logic when they have AddMinutes and AddHours! Damn them and their inconsistencies!

You could always create an extension method for .AddWeeks if it really bothers you, though:

public static class DateTimeExtensions
{
    public static DateTime AddWeeks(this DateTime dateTime, int numberOfWeeks)
    {
        return dateTime.AddDays(numberOfWeeks * 7);
    }
}

And as others have pointed out, a year is not 52 weeks.

The abstract Calendar class implements the method you're after, you can either use your locale's calendar, or create an object of a class that implements it:

DateTime dt = CultureInfo.InvariantCulture.Calendar.AddWeeks(datetime, weeks);

GregorianCalendar gc = new GregorianCalendar();
DateTime dt = gc.AddWeeks(datetime, weeks);

Ultimatey I expect the AddWeeks is missing purely to avoid massive numbers of methods. Maybe add an extension method:

public static DateTime AddWeeks(this DateTime from, int count) {
    return from.AddDays(7 * count);
}

I think it is because there are multiple definitions of Week Numbers out there i.e.

ISO definition of week number (https://en.wikipedia.org/wiki/ISO_week_date) is different from the North American definition of week number and across other cultures.

Why the above explanation matters for our context(why not have 'AddWeeks()')

Begining of 1st Week or ending of 52/53 week varies across different format/culture so while adding/subtracting if we cross that boundary i.e beginning of year or end of the year then one need additional information to determine the exact date for the given week number(Whether they are following ISO or local culture format, whether Monday is beginning day or Sunday e.t.c) which makes that function complex. I think it is for this reason they left it to us to figure out the week number.

If you literally like to add weeks and if you don't care about the week # definition then yes the above-proposed solution by Steve Morgan is smart enough.

yearOldPrice = _priceService.GetPriceForDate(price.Date.AddDays(-7 * 52); is what you want. Note that adding a year, and adding 52 weeks is different.

If you really want you could make an extension method:

public static class DateTimeExtensions
{
    public static DateTime AddWeeks(this DateTime DT, int Weeks)
    {
        return DT.AddDays(Weeks * 7);
    }
}

It would be slightly different. Subtracting 52 weeks is subtracting 364 days, whereas a year is 365 (366 on leap-years).

There is probably no AddWeeks() because it's easy enough to do AddDays(-7 * numWeeks) to subtract weeks.

As @Craig said: In Powershell you could solve it like this:

[int]$WeeksAgo = 52

(Get-Date).AddDays(-7 * $WeeksAgo)

It's same because week = 7 days (.AddDays(-7 * 52) == .AddWeeks(-52))

but 52 weeek is not a year (.AddDays(-7 * 52) != .AddYears(-1))

If they were specific about 52 weeks then I would use -7 * 52, as there are always 7 days in a week. Using .AddYear will take into account leap years, when an extra day exists.