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.
Related
I have to create a class that includes 3 methods.
1st - It shows current date
2nd - current date + 7days
3rd - current date - 7days.
I had completely dealing with dates in C # so i created sth that :
public class Date
{
private DateTime date = DateTime.Now;
public DateTime Now()
{
return date;
}
public DateTime AktuPlusOne ()
{
DateTime date = DateTime.Now.AddDays(7);
return date;
}
public DateTime AktuMinusOne()
{
DateTime date = DateTime.Now.AddDays(-7);
return date;
}
}
Is it ok or not ? It works fine, but I care about good habits .
No need to create additional method as framework already provides this functionality out of box DateTime.Now.AddDays(numberOfDays). However, if you really want to create a generic method for your requirement, just create one instead of three methods.
public DateTime AddDaysToToday(int days)
{
return DateTime.Now.AddDays(days);
}
DateTime today = AddDaysToToday(0);
DateTime todayPlusSeven = AddDaysToToday(7);
DateTime todayMinusSeven = AddDaysToToday(-7);
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?
I'm receiving a JSON date in the following format:
"launch_date": 1250553600
How should I modify the following to include a custom DateTime parser that allows me to convert that number into a DateTime object?
JsonConvert.DeserializeObject<NTask>(json);
public sealed class NTask
{
public DateTime launch_date { get; set; }
}
Alternatively I could use long and then parse it in another field but I'd rather avoid doing that, and have JsonConvert automatically parse it to DateTime through some converter.
You're going to want to use a JSONConverter to help manage the translation. See this stackapps answer for more detail.
Here is some code to do that:
// This is an example of a UNIX timestamp for the date/time 11-04-2005 09:25.
double timestamp = 1113211532;
// First make a System.DateTime equivalent to the UNIX Epoch.
System.DateTime dateTime = new System.DateTime(1970, 1, 1, 0, 0, 0, 0);
// Add the number of seconds in UNIX timestamp to be converted.
dateTime = dateTime.AddSeconds(timestamp);
For your code:
JsonConvert.DeserializeObject<NTask>(json);
public sealed class NTask
{
public DateTime launch_date { get; set; }
public void SetLaunchDate(int timestamp)
{
// First make a System.DateTime equivalent to the UNIX Epoch.
var dateTime = new DateTime(1970, 1, 1, 0, 0, 0, 0);
// Add the number of seconds in UNIX timestamp to be converted.
launch_date = dateTime.AddSeconds(timestamp);
}
}
Then when you are Deserializing the JSON, check to see if the launch_date is of type int or DateTime and switch how you set the object based on the type!
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.