Home |
Search |
Today's Posts |
#1
|
|||
|
|||
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 |
#2
|
|||
|
|||
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 |
#3
|
|||
|
|||
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? |
#4
|
|||
|
|||
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. |
#5
|
|||
|
|||
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 |
#6
|
|||
|
|||
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 |
#7
|
|||
|
|||
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 |
Reply |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
Why do I get a #Name error when I use the DateDif function? | Excel Worksheet Functions | |||
Why do I get a #Name error when I use the DateDif function? | Excel Worksheet Functions | |||
datedif | Excel Discussion (Misc queries) | |||
The 'DATEDIF' Function is not listed on my Excel program. | Excel Worksheet Functions | |||
Does Excel 2000 have a 'datedif' function to calculate the number. | Excel Worksheet Functions |