How do I Write C# code that will allow to compile the following code :
var date = 8.September(2013); // Generates a DateTime for the 8th of September 2013
You can use an extension method:
public static class MyExtensions
{
public static DateTime September(this int day, int year)
{
return new DateTime(year, 9, day);
}
}
However, this is generally bad practice, and I'd recommend against this kind of thing, especially for something as trivial as this—is new DateTime(2013, 9, 8) really so much more difficult than 8.September(2013)? There may be times where this kind of trick can be useful or fun for practice, but it should be used sparingly.
I would recommend against this, as it strikes me as very poor style. That said, if you really want to do this statically, you would need to define twelve different extension methods (one for each month name) like so:
public static class DateConstructionExtensions
{
public static DateTime January(this int day, int year)
{
return new DateTime(year, /* month: */1, day);
}
// equivalent methods for February, March, etc...
}
You could do this via extensions:
public static DateTime September(this int day, int year) {
return new DateTime(year, 9, day);
}
Of course, you'd need 12 such extensions, one for each month.
I think you can have the implementation like this:
public partial interface IMonth {
int Number {
get;
}
}
public partial class February: IMonth {
public int Number {
get {
return 2;
}
}
}
public static partial class Extensions {
public static DateTime OfMonth<T>(this int day, int year)
where T: IMonth, new() {
var month=new T();
var daysInMonth=DateTime.DaysInMonth(year, month.Number);
if(1>day||day>daysInMonth)
throw new ArgumentException();
return new DateTime(year, month.Number, day);
}
}
For the reason I declare months as classes, is because months might have different names in different cultures. You might want to provide different aliases for them.
Then, for the reason there's IMonth, is a contract that months must implement it. The extension method has the constraint new() is for avoiding IMonth itself or an abstract class be used.
This implementation also checks for the valid day number.
And you can assign the variable date as:
var date=(28).OfMonth<February>(2013);
Make sense?
Related
I am having the following class
public class MyDictionary : SortedList<int, MyData>
{
}
At the moment the Key in the SortedList represents a year number, e.g. 2014, 2015, 2016 etc. The Value represents the data for the year.
Now I have a new requirement saying that having a Value per year is not enough and this class should support a finer granularity.
The new granularity looks like this:
Yearly
Quarterly
Monthly
Weekly
Daily
Of course one instance of MyDictionary should represent one time frame, e.g. SortedList<Yearly, MyData>, SortedList<Monthly, MyData>.
The data that goes into MyDictionary spans over several years. That means that I cannot use, e.g. the number of a month in a monthly granularity. Example:
2014-12
2015-01
2015-02
...
2015-12
As you can see the number 12 is twice in the list.
My problem is, that I don't know what data type to use for the Key and how to access the Values in MyDictionary to meet the new requirement.
Any ideas?
Modification from 24.02.2016:
I must add a little more information to the original question.
The granularity is known at runtime only
The access to the Values via the array indexer [] must be runtime optimised. It will be called millions of times in a very short period of time.
The class that uses MyDictionary uses a DateTime object to access the Values. Example:
public class ClientClass
{
public void AccessMyDictionary(DateTime date)
{
MyData data = MyDictionary[date.Year];
// Do something with data
}
}
It looks to me that the most obvious thing to do is to have DateTime as an indexer data type. Then create an indexer in the MyDictionary class to take care of granularity. Example:
public enum Period
{
Yearly,
Quarterly,
Monthly,
Weekly,
Daily
}
public class MyDictionary
{
private Period period;
private SortedList<DateTime, MyData> sortedList;
public MyDictionary(Period period)
{
this.period = period;
sortedList = new SortedList<DateTime, MyData>();
}
public MyData this[DateTime i]
{
get
{
// Implement here an algorithm for granularity, similar to the one of Tomas Lycken in the 1st answer
}
set
{
// Implement here an algorithm for granularity, similar to the one of Tomas Lycken in the 1st answer
}
}
}
What do you think? Is that runtime optimised?
Many thanks
Konstantin
I would define some new value objects for the various granularities, all deriving from a common base class Period. You can then use as these keys. For example,
public abstract class Period { }
public class Quarter : Period
{
public int Quarter { get; }
public int Year { get; }
public Quarter(int year, int quarter)
{
if (year < 1800 || year > DateTime.UtcNow.Year)
{
throw new ArgumentOutOfRangeException(nameof(year));
}
if (quarter < 1 || quarter > 4)
{
throw new ArgumentOutOfRangeException(nameof(quarter));
}
Year = year;
Quarter = quarter;
}
}
And of course you'd define similar types for Year (which only has one property), Month (which has a year and a month, and the month must be between 1 and 12), Week (where validation becomes a little more tricky, since not all years have the same number of weeks), Day (don't forget to allow for leap years!).
Then, you also define equality and hashing for these types so that if their properties are equal, they are equal. (This is a good read on the topic!) For Quarter, I'd do something like
public class Quarter
{
// properties and constructor ommitted
public override bool Equals(object other)
{
if (!(other is Quarter))
{
return false;
}
var quarter = (Quarter)other;
return quarter.Year == Year && quarter.Quarter == quarter;
}
public override int GetHashCode()
{
unchecked // Overflow is fine, just wrap
{
// The two hard-coded digits below should be primes,
// uniquely chosen per type (so no two types you define
// use the same primes).
int hash = (int) 2166136261;
// Suitable nullity checks etc, of course :)
hash = hash * 16777619 ^ Quarter.GetHashCode();
hash = hash * 16777619 ^ Year.GetHashCode();
return hash;
}
}
}
Depending on how else you're going to use these, you might also want to override == and/or !=.
Now, these types are fully usable as keys in the dictionary, so you can do
var quarterlyReport = new SortedList<Quarter, Data>();
If you want to avoid having to define Equals and GetHashCode manually, most associative collections in .NET have a constructor which takes an equality comparer for the key type, that handles this for you. SortedList<TKey, TValue> has one too, so instead of overriding Equals and GetHashCode above you could create a pendant type for each period like
public class QuarterComparer : IComparer<Quarter>
{
int IComparer<Quarter>.Compare(Quarter p, Quarter q)
{
return p.Year < q.Year
? -1
: p.Year == q.Year
? p.Quarter < q.Quarter
? -1
: p.Quarter == q.Quarter
? 0
: 1
: 1;
}
public int Compare(Quarter p, Quarter q)
{
return (this as IComparer<Quarter>).Compare(p, q);
}
}
and pass this to the constructor of the sorted list:
var quarterlyData = new SortedList<Quarter, MyData>(new QuarterComparer());
As you know PCL doesn't support PersianCalendar or GregorianCalendar class, So I'm using generic to achieve that, In this case consumer can pass the Calendar to the class:
public class DateConvertor<TCalendar> where TCalendar : Calendar
{
public DateConvertor()
{
this.CurentCalendar = Activator.CreateInstance<TCalendar>();
}
public TCalendar CurentCalendar
{
get;
private set;
}
public DateTime GetDate(string date)
{
//....
var newDate = new DateTime(year, month, day, hour, minute, 0);
return newDate;
}
}
So I need pass a new instance of PersianCalendar to DateTime's constructor:
var newDate = new DateTime(year, month, day, hour, minute, 0, new PersianCalendar());
Now my question is that How can I do that? For example something like this:
var newDate = new DateTime(year, month, day, hour, minute, 0, CurentCalendar);
Can I pass a generic type as a parameter to DateTime's constructor?
Update:
It seems that DateTime class doesn't have that signature for accepting a new instance of Calendar in Portable Class Library:
public DateTime(
int year,
int month,
int day,
int hour,
int minute,
int second,
Calendar calendar
)
As you've noted, DateTime doesn't have the constructor you want in the PCL. However, you can use Calendar.ToDateTime:
return CurrentCalendar.ToDateTime(year, month, day, hour, minute, 0, 0);
As an aside, you could change your generic constraint to include new(), and just call the constructor:
public class DateConverter<TCalendar> where TCalendar : Calendar, new()
{
public DateConverter()
{
this.CurrentCalendar = new TCalendar();
}
}
Or use my Noda Time project which supports other calendars in a rather more pleasant way, IMO - e.g. a LocalDateTime "knows" the calendar it belongs to, and allows you to convert to a LocalDateTime in another calendar, etc.
I have a php code like this,going to convert it in to C#.
function HuntingDate()
{
Global $nameofselectbox,$startYear,$endYear,$year,
$startDate,$endDate,$startMounth,$endMounth,$startDay,$endDay;
$today = getdate();
$year=$today['year'];
$mounth=$today['mon'];
$day=$today['mday'];
Here is my try( I tried to use enum for this)
public enum HuntingDate{string StartYear,string EndYear,string Year,string StartDate,string EndDate,string StartMonth,string EndMonth,stirng StartDay,string EndDay}
Can i do thisone with enum ? i got the error "Identifier expected,String is a keyword"
No not with enum, you should use a class for this:
public class HuntingDate
{
string StartYear;
string EndYear;
string Year;
string StartDate;
string EndDate;
string StartMonth;
string EndMonth;
string StartDay;
string EndDay;
}
you then have further things to consider:
Strings are not ideal for date type data, for this consider using DateTime - with this you can merge the year, month and day values into one property:
public class HuntingDate
{
public DateTime StartDateTime;
public DateTime EndDateTime;
}
Classes are used to define the structure of an object, as my example stands you would need to create an instance of the class in order to use it:
HuntingDate huntingDate = new HuntingDate();
with this you have to consider where you want to have access to it. If you need a global accessible instance you could initialise the class at a global scope level, or consider using a static class (though it should be noted that these values would be persisted across the whole application):
public static class HuntingDate
{
public static string Something;
}
I would strongly suggesting doing some reading on C# (get a book!) if you want to do this more seriously you should get a solid grasp of the basics of C#
I guess you want the (string) values "StartYear", "EndYear" and so on as values of an enum.
You cannot do that: an enum is always based on some integer type.
I think you would be better off using the DateTime type for the start and end dates, and wrap it all in a class something like this:
public class HuntingDate
{
public HuntingDate(DateTime start, DateTime end)
{
_start = start;
_end = end;
}
public DateTime End
{
get
{
return _end;
}
}
public DateTime Start
{
get
{
return _start;
}
}
private readonly DateTime _start;
private readonly DateTime _end;
}
No, You can do this with enum. By default the underlying type of each element in the enum is int.
You can specify another integral numeric type by using a colon, as
shown in the example below. For a full list of possible types, see enum (C#
Reference).
Example:
enum Months : byte { Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec };
You can use struct or class type for this purpose.
public struct HuntingDate
{
int StartYear;
int StartMonth;
int StartDay;
int Year;
DateTime StartDate; // it smells like you are storing date then why do
// you not use DateTime rather than these..
DateTime EndDate;
int EndYear;
int EndMonth;
int EndDay;
}
If your Year it not necessary then it can be shorten as:
public struct HuntingDate
{
public DateTime StartDate;
public DateTime EndDate;
}
other wise go for the full values including Year.
bear i mind i don't know php from... well php...
function HuntingDate()
{
Global $nameofselectbox,$startYear,$endYear,$year,
$startDate,$endDate,$startMounth,$endMounth,$startDay,$endDay;
$today = getdate();
$year=$today['year'];
$mounth=$today['mon'];
$day=$today['mday'];
... rest of code
}
I'm guesstimating you'll need a class (and not an enum)
public class HuntingDate()
{
string NameOfSelectbox;
DateTime endDate;
rest of code ...
}
I saw there are lots of answers,WHAT IS THE BEST ANSWER ?
I have a system that takes information from an external source and then stores it to be displayed later.
One of the data items is a date. On the source system they have the concept of a fuzzy date i.e. not accurate to a specific day or sometimes not to a month as well. So I get dates in the format:
dd/mm/yyyy
mm/yyyy
yyyy
I can parse these to DateTime objects and work with these but when rendering later I need to be able to determine the accuracy of the date since parsing "2010" will result in a date of "01/01/2010". I want to show just the year so need to know it's original accuracy.
I've mocked up a quick class to deal with this:
public class FuzzyDate
{
public DateTime Date { get; set; }
public DateType Type { get; set; }
}
public enum DateType
{
DayMonthYear,
MonthYear,
Year
}
This will do the job for me and I can do something on the parse to handle it but I feel like this is probably quite a common problem and there is probably an existing cleaner solution.
Is there something built into .Net to do this? I had a look at the culture stuff but that didn't quite seem right.
Any help would be appreciated.
To answer your question: There is nothing built into .NET to handle this gracefully.
Your solution is as valid as any I've seen. You will probably wish to embellish your class with overrides to the ToString() method that will render your date appropriately based on the DateType.
Here are a couple other threads that attempt to address this question:
Strategy for Incomplete Dates
Implementing a "Partial Date" object
Good luck!
If your data type will always handle specific periods of time (i.e. the year 1972 is a specific period of time, but the 4th of July is not specific), you can store your data as a start time and time span.
If your date was "1972", the start date would be 19720101 and the time span would be 366 days.
If your date was "07/1972", the start date would be 19720701 and the time span would be 31 days.
If your date was "04/07/1972", the start date would be 19720704 and the time span would be 1 day.
Here's a possible implementation:
public struct VagueDate
{
DateTime start, end;
public DateTime Start { get { return start; } }
public DateTime End { get { return end; } }
public TimeSpan Span { get { return end - start; } }
public VagueDate(string Date)
{
if (DateTime.TryParseExact(Date, "yyyy", null, 0, out start))
end = start.AddYears(1);
else if (DateTime.TryParseExact(Date, "MM/yyyy", null, 0, out start))
end = start.AddMonths(1);
else if (DateTime.TryParseExact(Date, "dd/MM/yyyy", null, 0, out start))
end = start.AddDays(1);
else
throw new ArgumentException("Invalid format", "Date");
}
public override string ToString()
{
return Start.ToString("dd/MM/yyyy") + " plus " + Span.TotalDays + " days";
}
}
As I started to read your problem, I rapidly came to the conclusion that the answer was to implement your own FuzzyDate class. Lo and behold, that's exactly what you've done.
I can imagine that you might want to add functionality to this over time (such as comparisons that take into account the DateType).
I don't believe there's anything that will inherently help you in the .NET Framework, so I think you're doing the right thing.
I think you're going down the right route. There is no concept of a 'fuzzy' date or partial date, you will need to build your own.
You will likely need more constructor methods, for example
public FuzzyDate(int year)
{
Date = new DateTime(year,1,1); // 1 Jan yy
Type = DateType.Year;
}
public FuzzyDate(int year, int month)
{
Date = new DateTime(year, month, 1); // 1 mm yy
Type = DateType.MonthYear;
}
public FuzzyDate(int year, int month, int day)
{
Date = new DateTime(year, month, day); // dd mm yy
Type = DateType.DayMonthYear;
}
Hope this helps,
Kevin
It seems to me that your approach is right. Its true that .NET DateTime support multiple formats but I guess that given that all of them are supported with a concept of steps (nanoseconds), then will be related to specific date AND time.
One thing I would do differently is use null-able values (or use -1 for null semantics) for month and day to indicate what data was collected. Then I would have a factory method that would take a DateType param and return a DateTime. This method would throw and exception if only the year was available and the client code tried to create a DateType.DayMonthYear.
public class FuzzyDate
{
int _year;
int? _month;
int? _day;
public DateTime Date { get; set; }
public DateType Type { get; set; }
public DateTime GetDateTime(DateType dateType) { // ...
}
public enum DateType
{
DayMonthYear,
MonthYear,
Year
}
This might seem a bit over the top but the approach would explicitly store the original data and only represent "faked" DateTime objects when requested. If you were to persist a DateTime object internally along with a DateType enum you would lose some resolution.
As far as I am aware there is nothing built into .NET for this, the solution I'd go for is one based upon nullable values, something like this.
public class FuzzyDate
{
private int Year;
private int? Month;
private int? Day;
public FuzzyDate(int Year, int? Month, int? Day)
{
this.Year = Year;
this.Month = Month;
this.Day = Day;
}
public DateType DateType
{
get
{
if(Day.HasValue && Month.HasValue)
{
return DateType.DayMonthYear;
}
else if(Month.HasValue)
{
return DateType.MonthYear;
}
else
{
return DateType.Year;
}
}
}
public DateTime Date
{
get
{
return new DateTime(Year, Month.GetValueOrDefault(1), Day.GetValueOrDefault(1));
}
}
}
public enum DateType
{
DayMonthYear,
MonthYear,
Year
}
You could create your own structure (user-defined type) based on the datetime that would allow 00 for month, and 00 for day... And then also implement icomparable, so you can do math/comparrisons on it.
http://msdn.microsoft.com/en-us/library/k69kzbs1%28v=vs.71%29.aspx
http://msdn.microsoft.com/en-us/library/system.icomparable.aspx
This question already has answers here:
Unit Testing: DateTime.Now
(22 answers)
Closed last year.
I have this method which is dependent on current date. It checks if today is Sun, Mon, Tue or Wed, then it gives 5 days of lead time for arrival of shipped items. If its Thur, Fri or Sat then it gives 6 days of lead time to account for the weekend.
private DateTime GetEstimatedArrivalDate()
{
DateTime estimatedDate;
if (DateTime.Now.DayOfWeek >= DayOfWeek.Thursday)
{
estimatedDate = DateTime.Now.Date.AddDays(6);
}
else
{
estimatedDate = DateTime.Now.Date.AddDays(5);
}
return estimatedDate;
}
The actual estimation logic is more complex. I have simplified it for the purpose of this question. My question is how do I write a unit test for something like this which depends on todays date?
You need to pass the current date in as a parameter:
private DateTime GetEstimatedArrivalDate(DateTime currentDate)
{
DateTime estimatedDate;
if (currentDate.DayOfWeek >= DayOfWeek.Thursday)
{
estimatedDate = currentDate.AddDays(6);
}
else
{
estimatedDate = currentDate.AddDays(5);
}
return estimatedDate;
}
In real code you call it like this:
DateTime estimatedDate = GetEstimatedArrivalDate(DateTime.Now.Date);
Then you can test it as follows:
DateTime actual = GetEstimatedArrivalDate(new DateTime(2010, 2, 10));
DateTime expected = ...;
// etc...
Note that this also fixes a potential bug in your program where the date changes between consecutive calls to DateTime.Now.
Generally speaking, you'd want to abstract the method of obtaining the current date and time behind an interface, eg:
public interface IDateTimeProvider
{
DateTime Now { get; }
}
The real service would be:
public class DateTimeProvider: IDateTimeProvider
{
public DateTime Now
{
get
{
return DateTime.Now;
}
}
}
And a test service would be:
public class TestDateTimeProvider: IDateTimeProvider
{
private DateTime timeToProvide;
public TestDateTimeProvider(DateTime timeToProvide)
{
this.timeToProvide = timeToProvide;
}
public DateTime Now
{
get
{
return timeToProvide;
}
}
}
For services that require the current time, have them take an IDateTimeProvider as a dependency. For the real thing, pass a new DateTimeProvider(); when you're a component, pass in a new TestDateTimeProvider(timeToTestFor).
Make your class take an IClock parameter (via constructor or property)
interface IClock
{
DateTime Now { get; }
}
You can then use a fake implementation for testing
class FakeClock : IClock
{
DateTime Now { get; set }
}
and a real implementation the rest of the time.
class SystemClock : IClock
{
DateTime Now { get { return DateTime.Now; } }
}
I would suggest doing this as Mark suggests, but with the addition of a overloaded call for production use that takes no parameter and uses DateTime.Now
private DateTime GetEstimatedArrivalDate()
{
return GetEstimatedArrivalDate(DateTime.Now);
}
private DateTime GetEstimatedArrivalDate(DateTime currentDate)
{
DateTime estimatedDate;
if (currentDate.DayOfWeek >= DayOfWeek.Thursday)
{
estimatedDate = currentDate.AddDays(6);
}
else
{
estimatedDate = currentDate.AddDays(5);
}
return estimatedDate;
}
One "common" way of doing so is to "fake" the current system date (that can be done in several ways) and then test your code on "known" dates.
Another interesting way is to change your implementation slightly to:
private DateTime GetEstimatedArrivalDate()
{
return GetEstimatedArrivalDate(DateTime.Now);
}
private DateTime GetEstimatedArrivalDate(DateTime forDate)
{
DateTime estimatedDate;
if (forDate.DayOfWeek >= DayOfWeek.Thursday)
{
estimatedDate = forDate.Date.AddDays(6);
}
else
{
estimatedDate = forDate.Date.AddDays(5);
}
return estimatedDate;
}
And then use the method with a parameter to test on "immediate" dates.
Seems like there are a limited enough number of cases that you could test them each explicitly. The method depends on today's date, but the output depends only on the day of week, and every date has a day of week.
You could pass in a delegate that returns DateTime.Now during normal execution, and then in your test pass in another delegate that returns a fixed date, and assert your result based on that.
I'll give the controversial answer, don't test it.
The logic is trivial and it has zero dependencies, i believe in good code coverage but not when it increases complexity for no real gain.