Is Datedif Outdated ?
 

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

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" wrote in message
...
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

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 ,
"RagDyeR" 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?

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 ,
"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.

On Thu, 2 Jun 2005 08:46:09 -0700, "RagDyeR" 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

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.

Appreciate the comments.

Regards,

RD

"RagDyeR" wrote in message
...
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

On Thu, 2 Jun 2005 13:52:18 -0700, "RagDyer" wrote:

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

I would agree.


--ron