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
Related
StartTime
AgentId
08/19/2021 07:04:56 AM UTC
33
08/11/2021 02:58:35 PM IST
42
08/12/2021 01:01:51 AM CST
24
08/12/2021 08:52:34 PM UTC
61
public class MyModel
{
public string StartTime { get; set; }
public int AgentId { get; set; }
public string TimeZone { get; set; }
public string Time { get; set; }
}
I have the above C# Class model MyModel and its sample data stored as a List<MyModel> in my logic. I need a help to parse the StartTime field of a list such that, the TimeZone field should get the UTC/CST/IST of its corresponding StartTime and Time field of a list should be time stamp from its StartTime i,e: 07:04:56 or 02:58:35 and so on. Finally the list should look like something like below:
StartTime
AgentId
Time
TimeZone
08/19/2021 07:04:56 AM UTC
33
07:04:56 AM
UTC
08/11/2021 02:58:35 PM IST
42
02:58:35 PM
IST
08/12/2021 01:01:51 AM CST
24
01:01:51 AM
CST
08/12/2021 08:52:34 PM UTC
61
08:52:34 PM
UTC
Given the fact that all of the segments in your StartTime property have a forced amount of characters thanks to the string format you've chosen (except for the timezone where we could have e.g. CEST but we don't have to worry about that and I'll get to the why in just a second) we can simply use the String.Substring method and for the first parameter, define the character from where the newly to be outputted string should start reading and as the second parameter, the amount of characters it should read from there on out. If we don't set the second parameter the String.Substring method will simply read the string to the very end and since the timezone is the last segment of the StartTime format, the unknown amount of characters for the timezone is no problem for us.
With that in mind, here are some options you can choose from:
If you don't want to adjust your class:
private void ManageMyModels(List<MyModel> models)
{
models.ForEach(model =>
{
model.TimeZone = model.StartTime.Substring(23);
model.Time = model.StartTime.Substring(11, 11);
});
}
This solution is pretty simple as it just iterates over every MyModel element and sets the TimeZone and Time property values accordingly to the StartTime value. However, it would be a lot nicer if we didn't always had to do this manually for every model we create so here's a better solution if you don't mind adjusting your class:
public class MyModel
{
public string StartTime { get; set; }
public int AgentId { get; set; }
public string TimeZone => this.StartTime.Substring(23);
public string Time => this.StartTime.Substring(11, 11);
}
The way this solution works is, whenever you access either the TimeZone or Time property, its assigned code will be executed returning the substring that you need. Performance wise there would be a disadvantage where the code would be executed every time you call either of the properties even when the StartTime value hasn't changed.
Alternatively you could do it the other way around where every time you pass a new value to the StartTime both of the properties would be updated as well:
public class MyModel
{
private string _startTime;
public string StartTime
{
get => _startTime;
set
{
this._startTime = value;
this.TimeZone = value.Substring(23);
this.Time = value.Substring(11, 11);
}
}
public int AgentId { get; set; }
public string TimeZone { get; private set; }
public string Time { get; private set; }
}
This eliminates previously mentioned disadvantage but creates a new one where the TimeZone and Time property will always be updated whenever the StartTime property is, even if you wouldn't use it.
Personally, I'd stick to the previous option simply because it's shorter and easier to read.
I want to save production year and month on an entity. I don't want to save the time and date of the month.
I can come up with multiple solutions, and the best two so far is:
public class Product
{
private DateTime _productionMonth;
public DateTime ProductionMonth
{
get => _productionMonth;
set => _productionMonth = new DateTime(value.Year, value.Month, 1);
}
}
or
public class Product
{
public int Year { get; set; }
public int Month { get; set; }
}
But I don't feel any of the solutions is the perfect solution...
Does there exists any better solutions? Maybe an attribute on DateTime?
You could store it as a single integer, using YYYYMM format. The entity can expose unmapped ([NotMapped]) helper methods to covering to/from DateTime, and/or a ValueTuple (year int, month int) though from EF queries you would need to use the single mapped value. YYYYMM are sortable so you can query a range efficiently.
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?
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.