How NOT to calculate the end of month...
-
Actually, he had unit tests in place, but all the dates tested were on the first day of the month. My fix was:
return new DateTime(dt.Year, dt.Month, 1).AddMonths(1).AddDays(-1);
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
:doh: I guess it's true for tests as well: GIGO ... :laugh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
Actually, he had unit tests in place, but all the dates tested were on the first day of the month. My fix was:
return new DateTime(dt.Year, dt.Month, 1).AddMonths(1).AddDays(-1);
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
And why not simply use
DateTime.DaysInMonth?It does not solve my Problem, but it answers my question
-
Actually, he had unit tests in place, but all the dates tested were on the first day of the month. My fix was:
return new DateTime(dt.Year, dt.Month, 1).AddMonths(1).AddDays(-1);
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Rob Grainger wrote:
but all the dates tested were on the first day of the month.
:laugh: :laugh: :laugh:
Latest Articles:
Abusing Extension Methods, Null Continuation, and Null Coalescence Operators -
Found this gem in our codebase...
public static class DateTimeExtensions
{
public static DateTime EndOfMonth(this DateTime dt)
{
return dt.Date.AddMonths(1).AddDays(-1);
}
}"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Not to be pernickity but I guess it is going to depend on the intention of the method. If a trial runs for a month then perhaps from a given date that would be the end of the month :) However, the intention is not clear from the method name so one may very well assume that it represents the date for the last day in the month of the given date.
-
Not to be pernickity but I guess it is going to depend on the intention of the method. If a trial runs for a month then perhaps from a given date that would be the end of the month :) However, the intention is not clear from the method name so one may very well assume that it represents the date for the last day in the month of the given date.
Personally, I feel that an extension method on DateTime should apply to all possible DateTime instances. Otherwise, it can be defined to match circumstances, as long as that is clear from the name.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Found this gem in our codebase...
public static class DateTimeExtensions
{
public static DateTime EndOfMonth(this DateTime dt)
{
return dt.Date.AddMonths(1).AddDays(-1);
}
}"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Actually, he had unit tests in place, but all the dates tested were on the first day of the month. My fix was:
return new DateTime(dt.Year, dt.Month, 1).AddMonths(1).AddDays(-1);
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
I resemble that remark.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Actually, he had unit tests in place, but all the dates tested were on the first day of the month. My fix was:
return new DateTime(dt.Year, dt.Month, 1).AddMonths(1).AddDays(-1);
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
This gets you the last *date* of the month, but if you’re actually looking for the “end” of the month and don’t want fencepost errors, you’d want the first of the next month (with no time component) and then use a strict less-than in your comparisons.
