# Is Datedif Outdated ?

RagDyeR
Guest
Posts: n/a

 2nd Jun 2005
About to start out on a seniority project for the plants.

If this was 3 months ago, I wouldn't have given a second thought about using
Datedif.

However, in the past couple of weeks, I've read, and been part of threads
where the inconsistencies of the function have been brought to light.

Of course, seniority will range over the full gamut of time, from days to
years.

Would you please just share with me your opinion on the function?

Would YOU use it ... or not?

TIA,

RD

Bernie Deitrick
Guest
Posts: n/a

 2nd Jun 2005
RagDyeR,

For seniority, simply finding the earliest (least) start date should be
sufficient: If I started before you, then I am senior to you.

HTH,
Bernie
MS Excel MVP

"RagDyeR" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> About to start out on a seniority project for the plants.
>
> If this was 3 months ago, I wouldn't have given a second thought about

using
> Datedif.
>
> However, in the past couple of weeks, I've read, and been part of threads
> where the inconsistencies of the function have been brought to light.
>
> Of course, seniority will range over the full gamut of time, from days to
> years.
>
> Would you please just share with me your opinion on the function?
>
> Would YOU use it ... or not?
>
>
> TIA,
>
> RD
>
>

JE McGimpsey
Guest
Posts: n/a

 2nd Jun 2005
> Would YOU use it ... or not?

Depends on what I was using it for. There's really no inconsistency in
DATEDIF. It works absolutely consistently, and if you know how it works,
you can absolutely predict the results. The problem is that "month" is
used inconsistently in problem statements.

To get

X years, Y months, Z days

where Z is calculated as =DATEDIF(date1,date2,"md"), definitely not. To
use the "y", "m", or "yd" switch, perhaps.

OTOH, there's absolutely no function that can provide a general solution
to the problem of the above format for, say,

date1 = 31 January 2005
date2 = 1 March 2005

Since "months" is an inherently fuzzy concept, the number of months and
days is also fuzzy, and has more than one valid solution. If one chooses
a particular definition of month, then a consistent algorithm can be
developed.

If this is to be used for decision making (e.g., promotions, layoffs,
etc.), it's absolutely critical that you use an algorithm that matches
the HR policy at the plants. How do *they* define months and days of
service? Make your algorithm (whether using formulas or a UDF) conform
exactly to their specifications.

In article <#(E-Mail Removed)>,
"RagDyeR" <(E-Mail Removed)> wrote:

> About to start out on a seniority project for the plants.
>
> If this was 3 months ago, I wouldn't have given a second thought about using
> Datedif.
>
> However, in the past couple of weeks, I've read, and been part of threads
> where the inconsistencies of the function have been brought to light.
>
> Of course, seniority will range over the full gamut of time, from days to
> years.
>
> Would you please just share with me your opinion on the function?
>
> Would YOU use it ... or not?

JE McGimpsey
Guest
Posts: n/a

 2nd Jun 2005
That may be sufficient for Ragdyer's purposes, but in my experience,
"seniority" depends on a number of factors. Unfortunately, in most
companies that I've worked with, raw dates aren't anywhere near
sufficient. A company often has employees with breaks in service, or
reduced credit for part time, etc. Key employees may be hired with added
months or years of seniority.

Also, many benefit plans that use seniority to determine benefit levels
use months and years, not days, and have arbitrary rules regarding when
during the month credit accrues.

At one company I worked for, I worked for 6 months, left, then was
rehired after an additional 11 months. When rehired, I was given credit
for my six months plus four years and six months credit toward my pay
grade seniority (which determined my salary range and eligibility for
bonuses), 5 years credit toward vacation time (with 30 days accrued
vacation), 17 months credit toward vesting in the profit sharing
program, and 7 months credit toward vesting in the 401K match (because I
actually left at 6 months and 3 days, or something like that).

So my "seniority" had very little to do with my hire date (either
original or subsequent), and DATEDIF wouldn't have begun to be
sufficient.

In article <(E-Mail Removed)>,
"Bernie Deitrick" <deitbe @ consumer dot org> wrote:

> For seniority, simply finding the earliest (least) start date should be
> sufficient: If I started before you, then I am senior to you.

Ron Rosenfeld
Guest
Posts: n/a

 2nd Jun 2005
On Thu, 2 Jun 2005 08:46:09 -0700, "RagDyeR" <(E-Mail Removed)> wrote:

>About to start out on a seniority project for the plants.
>
>If this was 3 months ago, I wouldn't have given a second thought about using
>Datedif.
>
>However, in the past couple of weeks, I've read, and been part of threads
>where the inconsistencies of the function have been brought to light.
>
>Of course, seniority will range over the full gamut of time, from days to
>years.
>
>Would you please just share with me your opinion on the function?
>
>Would YOU use it ... or not?
>
>
>TIA,
>
>RD
>

I think the important concept is to first define precisely how seniority will
be calculated. And what will be done with the results.

Once that is done, then you can devise appropriate worksheet functions.

The basic problem in defining time in terms of years, months and days is that
both years and months can vary in length. If you are trying to define time in
service, you could use weeks and days in order to be most accurate; or the
company could make a decision that they will count (for example) full calendar
months and fractions of a month; or make each month arbitrarily 30 days and
each year arbitrarily 360 days; or any other number of conventions.

Then you can decide how to treat 1/2 days of work on a Sunday Holiday :-))

--ron

RagDyer
Guest
Posts: n/a

 2nd Jun 2005
I know *exactly* what I'm going to do as far as the procedures are
concerned, and everything is conceptually consistent with historical company
performance.

So ... as I read it here, and as I remind myself what I've read in those
past threads, I should have *no* problem by switching to a strictly "day"
computation policy.

Regards,

RD

"RagDyeR" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> About to start out on a seniority project for the plants.
>
> If this was 3 months ago, I wouldn't have given a second thought about

using
> Datedif.
>
> However, in the past couple of weeks, I've read, and been part of threads
> where the inconsistencies of the function have been brought to light.
>
> Of course, seniority will range over the full gamut of time, from days to
> years.
>
> Would you please just share with me your opinion on the function?
>
> Would YOU use it ... or not?
>
>
> TIA,
>
> RD
>
>

Ron Rosenfeld
Guest
Posts: n/a

 3rd Jun 2005
On Thu, 2 Jun 2005 13:52:18 -0700, "RagDyer" <(E-Mail Removed)> wrote:

>I should have *no* problem by switching to a strictly "day"
>computation policy.

I would agree.

--ron

 Thread Tools Rate This Thread Rate This Thread: 5 : Excellent 4 : Good 3 : Average 2 : Bad 1 : Terrible

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are Off Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post UTCHELP Microsoft Excel Worksheet Functions 14 17th Nov 2005 11:30 AM Patrick O'Neill Windows XP Security 1 9th Mar 2004 02:50 PM Patrick O'Neill Windows XP Security 1 9th Mar 2004 02:12 PM =?Utf-8?B?SWRhZ3Jlc3M=?= Windows XP Performance 1 29th Oct 2003 12:42 PM Drew Windows XP General 1 1st Sep 2003 03:14 PM

Features