DateDiff equiv in C#??

  • Thread starter Thread starter SilentCry
  • Start date Start date
S

SilentCry

i know i could use the DateTime.DaysOfYear method to get the difference
between 2 dates in days but what if the 2 dates are in 2 different years?
DateDiff takes this into account but it doesn't exist in C#..
 
Use the TimeSpan class

TimeSpan ts = objDate1.Subtract(objDate2)

ts.TotalDays or ts.Days after that should suffice

Cheers
Jonathan Rucker


----- SilentCry wrote: ----

i know i could use the DateTime.DaysOfYear method to get the differenc
between 2 dates in days but what if the 2 dates are in 2 different years
DateDiff takes this into account but it doesn't exist in C#.
 
Man, you're such an idealist!!

Just reference the Microsoft.VisualBasic namespace and use the method
you want - oh, but that wouldn't be ***pure*** C#.
 
Jimi,

Is there anything wrong with not having to include yet another assembly
in your application distribution when there are the nesseccary functionality
in the System namespace? The DateDiff function uses a TimeSpan internally
anyway (along with some other stuff) =)

//Andreas

Jimi said:
Man, you're such an idealist!!

Just reference the Microsoft.VisualBasic namespace and use the method
you want - oh, but that wouldn't be ***pure*** C#.
Click to expand...
 
The reason I went away from vb and to C# instead of VB.NET is to force
myself to adopt new *better* programming principles.
If I have to constantly think about what I am doing it is a good thing as I
am constantly analysing my code. This occurrs when learning a *new* language
such as c#.
So far I have not had any time when I've been stumped for a solution and
have even wanted to reference the VB namespace and I *know* my programming
has improved.
If I ever find myself or anyone at my company referencing the VB namespace I
will spend the rest of the week if necessary working out a way to accomplish
what they / I are trying to do without referencing VB.

Cheers
JB

P.S. I dont know if your statement was tongue in cheek or not but there are
a lot of *lazy* vb programmers out there (myself included) that need a new,
better way.

Jimi said:
Man, you're such an idealist!!

Just reference the Microsoft.VisualBasic namespace and use the method
you want - oh, but that wouldn't be ***pure*** C#.
Click to expand...
 
I find it very strange that people are endlessly asking "how do I
re-code from scratch this or that method from the VB namespace", when
all they have to do is use the existing functionality - these methods
were coded by perfectly competent programmers at Microsoft.

I think the average programmer switching from VB to C# must spend days
recoding their favorite VB namespace methods. Do you think you're
going to end up with something very superior to the VB methods?

Forget about purity or pride - just use the existing functionality -
instead of forging your own, which will never work exactly the same
as the original anyway.

What would you think of your fellow developers at work who re-code
functionality already in place? You would think that they don't
really understand what's important.
 
John said:
The reason I went away from vb and to C# instead of VB.NET is to force
myself to adopt new *better* programming principles.
If I have to constantly think about what I am doing it is a good thing as I
am constantly analysing my code. This occurrs when learning a *new* language
such as c#.
So far I have not had any time when I've been stumped for a solution and
have even wanted to reference the VB namespace and I *know* my programming
has improved.
If I ever find myself or anyone at my company referencing the VB namespace I
will spend the rest of the week if necessary working out a way to accomplish
what they / I are trying to do without referencing VB.
Click to expand...

If you think of the Microsoft.VisualBasic assembly the same way as a
third party assembly, or even a utility assembly that you wrote, would
you still have the same view?

Basically that's what it is - a utility assembly that has the distinct
advantage of not needing deployment since it's installed along with the
Framework.
Cheers
JB

P.S. I dont know if your statement was tongue in cheek or not but there are
a lot of *lazy* vb programmers out there (myself included) that need a new,
better way.
Click to expand...
 
Mike,

I do not have any solid information on this, but isn't the
Microsoft.VisualBasic
name space a transitional namespace which won't be supported for very long?
I
am not sute, but I think it will be in Whideby but what about Orca?

//Andreas

mikeb said:
John said:
The reason I went away from vb and to C# instead of VB.NET is to force
myself to adopt new *better* programming principles.
If I have to constantly think about what I am doing it is a good thing as I
am constantly analysing my code. This occurrs when learning a *new* language
such as c#.
So far I have not had any time when I've been stumped for a solution and
have even wanted to reference the VB namespace and I *know* my programming
has improved.
If I ever find myself or anyone at my company referencing the VB namespace I
will spend the rest of the week if necessary working out a way to accomplish
what they / I are trying to do without referencing VB.
Click to expand...

If you think of the Microsoft.VisualBasic assembly the same way as a
third party assembly, or even a utility assembly that you wrote, would
you still have the same view?

Basically that's what it is - a utility assembly that has the distinct
advantage of not needing deployment since it's installed along with the
Framework.
Click to expand...
 
Andreas said:
Mike,

I do not have any solid information on this, but isn't the
Microsoft.VisualBasic
name space a transitional namespace which won't be supported for very long?
I
am not sute, but I think it will be in Whideby but what about Orca?
Click to expand...

I haven't heard this. I'd think that removing it would cause needless
headaches supporting VB.NET programs compiled with earlier versions of
the Framework as well as cause the new framework to have to support the
VB.NET functions some other way (intrinsic to the compiler, maybe?). Why
would MS bother? If there's a link to information about this, I'd
appreciate a pointer.

One actual drawback with using types in the Microsoft.VisualBasic
assembly is that it's not documented for use by C#, and the full
typenames are not always documented. So to be able to use the classes
in it you sometimes have to dig a little for the information you need.

I'm not advocating going out of the way to use this stuff from C#, it's
just that if it happens to already have exactly what you need, I see no
particular reason to avoid using it.
 
Mike,

This was pure speculation from my end. I believe that the functionality
in the Microsoft.VisualBasic is aimed to mimic functionality from VB(6),
so that the project converter and people moving from VB(6) will get a
headstart.

To be honest? I think it's the name that scares people away from using it
in thier code. And because of the name, I get a feeling that it is some sort
of transitional namespace or why not make the functionality a part of the
normal system.* namespaces, and include stuff like DateDiff directly into
the DateTime structure? It's small things like this, which makes me thing
it's a transitional namespace.


//Andreas
 
Andreas said:
Mike,

This was pure speculation from my end. I believe that the functionality
in the Microsoft.VisualBasic is aimed to mimic functionality from VB(6),
so that the project converter and people moving from VB(6) will get a
headstart.

To be honest? I think it's the name that scares people away from using it
in thier code. And because of the name, I get a feeling that it is some sort
of transitional namespace or why not make the functionality a part of the
normal system.* namespaces, and include stuff like DateDiff directly into
the DateTime structure? It's small things like this, which makes me thing
it's a transitional namespace.
Click to expand...

There's no doubt that these functions are there because they were in
VB6. However, now they're in the VB.NET spec, so I can't see MS
removing them. I suppose it's possible that they'd change the underlying
implementation, but again, why would they?

And if that's a real concern then someone wanting to use DateDiff (for
example) from C# could write a public class in VB.NET that wrapped the
DateDiff function, then use that class from C#. That's a fundamental
part of the .NET Framework philosophy, and if MS broke that, then I'd
think many, many people would bail on .NET altogether.

DateDiff() does not seem to be a trivial function to write. If someone
wants to duplicate the functionality of DateDiff() because they don't
want to use VB.NET's implementation, I guess that's their business.
But, it seems a waste.
 
Jimi said:
Forget about purity or pride - just use the existing functionality -
instead of forging your own, which will never work exactly the same
as the original anyway.
Click to expand...

The comparison here is between an existing and well-supported way of
doing something idiomatically in C# (namely subtracting one DateTime
from another to give a TimeSpan) and using something from the
VisualBasic namespace which as far as I can see isn't documented in
MSDN.

What's the advantage of the latter, exactly?
 
mikeb said:
DateDiff() does not seem to be a trivial function to write. If someone
wants to duplicate the functionality of DateDiff() because they don't
want to use VB.NET's implementation, I guess that's their business.
But, it seems a waste.
Click to expand...

No-one has suggested reimplementing the whole of DateDiff in their own
code though - they've suggested that for the OP's question, using the
subtraction operator with two DateTimes to give a TimeSpan is a more
idiomatic solution.
 
The original post was a request for something equivalent to DateDiff.
Well, DateDiff can be used from C# and since DateDiff is identical to
DateDiff since it is DateDiff, the functionality is exactly what
anyone familiar with DateDiff would expect. Why not use it? The
only answer I can discern is ideology.

What you'll end up with is every ex-VB programmer will code their own
flavor of "JoesDateDiff", coded to mimic VB's DateDiff as close as
possible. Why is this better than the original DateDiff? DateDiff
has been time tested - JoesDateDiff hasn't. Gee, it seems kind of
simple ...
 
Jimi said:
The original post was a request for something equivalent to DateDiff.
Click to expand...

The original post wanted to know the number of days between two dates.
The simplest way of achieving that is:

int days = (int)(secondDate-firstDate).TotalDays;

If you want it rounded up, use Math.Ceil.

Now, are you suggesting that TimeSpan hasn't been tested properly?

I would suggest that TimeSpan has actually been tested rather *more*
thoroughly than DateDiff, as DateDiff will mostly have been used by
VB.NET programmers, whereas just about everyone will be using TimeSpan
somewhere or other (even if they don't know it).

Using TimeSpan instead of DateDiff has the following advantages:
o TimeSpan being part of the core .NET framework, it will have been
tested more thoroughly than DateDiff
o TimeSpan being part of the core .NET framework, it's more familiar
to most C# programmers. Don't forget the importance of readability,
and the fact that many C# programmers will never have used VB.
o TimeSpan being part of the core .NET framework, it's more likely
to be available in other CLRs such as Mono, ROTOR etc.
o TimeSpan being part of the core .NET framework means that you don't
need to reference any other assemblies.
o TimeSpan is documented in MSDN. Where is DateDiff documented in MSDN
for a C# programmer? It's not mentioned in the VisualBasic namespace
documentation.
o TimeSpan has a convenient syntax due to operator overloading.

So, what exactly do you believe the advantages of DateDiff are again?
 
Jon said:
No-one has suggested reimplementing the whole of DateDiff in their own
code though - they've suggested that for the OP's question, using the
subtraction operator with two DateTimes to give a TimeSpan is a more
idiomatic solution.
Click to expand...

Sorry... I'm contributing to the drift of this thread. My comments at
this point are not necessarily directed at the original poster's
question, but rather at the dogmatic stance of *never* considering using
functionality implemented in Microsoft.VisualBasic from a C# program. I
guess I used DateDiff() in my examples, since it's mentioned in the thread.

It all started (for me anyway) when I read a post that said:

As I said previously, I would not go out of my way to use VB.NET
functions in a C# program, but if there's functionality there that's
exactly what's needed (and there's no ready equivalent otherwise) I see
no problem in using the VB.NET functionality.

If all you need is the number of days between 2 dates, then definitely

(DateTime2 - DateTime1).TotalDays

is the way to go. if you need the more complex calendar support provided
by DateDiff(), then I say use DateDiff().

I should probably stop now.
 
Sorry about the tone of my last post, but all I'm trying to say is
that if there's a VB method you're used to, then by all means just
keep using it - no fuss, no muss. Personally, I've replaced some
with my own versions, but I began to realize I was just doing it for
purity's sake, not because it made financial sense to recode what was
there already. There's no extra baggage - Microsoft.VisualBasic is
part of the framework.

If the VB methods were from another namespace, called say
"System.SuperDuper", then we wouldn't even be having this discussion.
 
Jimi said:
Sorry about the tone of my last post, but all I'm trying to say is
that if there's a VB method you're used to, then by all means just
keep using it - no fuss, no muss. Personally, I've replaced some
with my own versions, but I began to realize I was just doing it for
purity's sake, not because it made financial sense to recode what was
there already.
Click to expand...

But most of the time there's a perfectly reasonable .NET way of doing
things. For instance, using String.Substring instead of Right, TimeSpan
instead of DateDiff etc.
There's no extra baggage - Microsoft.VisualBasic is part of the framework.
Click to expand...

Well, that depends on what you really think of as "the framework". It's
certainly not "core" - and it's one of the things I wouldn't expect to
find in any other CLR (although I gather Mono is starting to include
some of it). The fact that it's not documented in MSDN in the same way
as the rest of the framework is quite telling, IMO.
If the VB methods were from another namespace, called say
"System.SuperDuper", then we wouldn't even be having this discussion.
Click to expand...

But most of the VB methods *are* in the framework in some slightly
different form - and given that, I see no reason to start coding C# in
VB idioms.

If you still think in VB terms, you're not likely to write idiomatic C#
- and some of the worst code I've seen has been people trying to write
in one language as if they were writing in another. (Specifically,
writing Java as if it were C++ produces dreadful results.)

Before using anything from the VisualBasic namespace I would *always*
suggest trying to see whether there's an idiomatic .NET way of doing it
instead - and usually there will be.
 
Back
Top