DateDiff for C# - SR

  • Thread starter Thread starter sr
  • Start date Start date
S

sr

Anyone know of a better way to simulate a datediff for C#, i.e.,
without referencing the VB.NET runtime?

Only added the functionality that was needed for me so it is not
the full implementation of the DateDiff in the VB.NET runtime.

private int DateDiff( string Interval, DateTime Date1, DateTime Date2 )
{
int intDateDiff = 0;
TimeSpan time = Date1 - Date2;
int timeHours = Math.Abs( time.Hours );
int timeDays = Math.Abs( time.Days );

switch(Interval.ToLower())
{
case "h": // hours
intDateDiff = timeHours;
break;
case "d": // days
intDateDiff = timeDays;
break;
case "w": // weeks
intDateDiff = timeDays / 7;
break;
case "bw": // bi-weekly
intDateDiff = (timeDays / 7) / 2;
break;
case "m": // monthly
timeDays = timeDays - ((timeDays / 365) * 5);
intDateDiff = timeDays / 30;
break;
case "bm": // bi-monthly
timeDays = timeDays - ((timeDays / 365) * 5);
intDateDiff = (timeDays / 30) / 2;
break;
case "q": // quarterly
timeDays = timeDays - ((timeDays / 365) * 5);
intDateDiff = (timeDays / 90);
break;
case "y": // yearly
intDateDiff = (timeDays / 365);
break;
}

return intDateDiff;
}

SR
 
I'm not sure why you'd want a function "just like datediff" for c#.. and if
you do, why not reference the vb.net namespace?

(it's not the vb.net *runtime*... vb.net and c# use exactly the same
runtime. the vb.net namespace / assembly is just another batch of .net
code)
 
Sr,
Rather then attempt to reinvent the wheel; why not simply reference the
Microsoft.VisualBasic assembly, then you can use the
Microsoft.VisualBasic.DateAndTime.DateDiff function?

using Microsoft.VisualBasic;
private int DateDiff( DateInterval interval, DateTime date1, DateTime
date2 )
{
Click to expand...
return DateAndTime.DateDiff(interval, date1, date2,
FirstDayOfWeek.Sunday, FirstWeekOfYear.Jan1)
}
Click to expand...

The Microsoft.VisualBasic is installed with the Framework itself, so it's
"guaranteed" on being available...

If you choose not to use Microsoft.VisualBasic: I would simply use the
various properties of TimeSpan rather then define the timeHours & timeDays
variables, and define an Enum for the interval.

Something like:

enum DateInterval
{
Hours
Days
}
TimeSpan time;
Click to expand...
if (Date1 < Date2)
time = Date2 - Date1;
else
time = Date1 - Date2;
switch(interval)
case DateInterval.Hours return time.TotalHours;
break;
case DateInterval.Days return time.TotalDays;
break;
Click to expand...
....
default:
throw new ArgumentOutOfRange( "interval", interval, "Invalid
interval value")
}

Hope this helps
Jay
 
I commend your rare common sense Jay !

I've always thought that if an assembly has something you find useful,
then why in the world would you want to rewrite it just because of the
assembly's name?

*-----------------------*
Posted at:
www.GroupSrv.com
*-----------------------*
 
I hear ya when someone besides MSFT writes a component and you
reference the component... that is what a component language is about.
But I don't feel .net should go down the path of referencing another
language runtime for every class that has common business functions
that any language should have innately available. Put those common
helper classes and enums into the system namespace exactly where the
Math class is! (all .net languages should have them available in the
system namespace - shouldn't have to reference another language).
Think how pissed VB coders would be if MSFT removed the DateAndTime
class from the vb.net runtime, but put it into the C# language only.
Then every VB.NET program would have to reference the C# runtime and
namespace in order to use it. Microsoft needs to create new FCL
Financial and DateAndTime classes (using decimal instead of double
where when dealing with currency) that are part of the core of the .net
framework. No one wants to write all that crap over and over again.
Sucks that I got to convert everything from decimal to double then back
to decimal. Would love to get rid of all my VB wrapper methods!
 
sr,
Financial ... classes (using decimal instead of double
where when dealing with currency)
Click to expand...
I never really understood why the (.NET) Financial class uses double instead
of Decimal either, I would think Decimal would be the far more logical
course for Financial objects! Only reason I can see them using Double is
historic reasons...

I objectized (encapsulated into classes) the Financial functions someplace,
I should dust them off & put them on my blog...
Put those common
helper classes and enums into the system namespace exactly where the
Math class is! (all .net languages should have them available in the
system namespace - shouldn't have to reference another language).
Click to expand...
Should they be in System? I would leave them in the Microsoft namespace and
consider removing them from the VisualBasic namespace, however I don't think
they need to be in the System namespace. Similar to how there are functions
in the Microsoft.Win32 namespace. And no they should not be in the Win32
namespace either, unless they deal specifically with Win32! I'm thinking
more simply Microsoft.DateAndTime & Microsoft.Financial.
I hear ya when someone besides MSFT writes a component and you
reference the component...
Click to expand...
Microsoft should be able to (and should!) create components just like any
other company! I hope you are not suggesting they cannot nor should not!

Just a thought
Jay
 
Back
Top