Fuzzy Dates in Attributes

Has anybody implemented any attributes that allow for fuzzy dates? I'm trying to find a way to handle the fact that we don't always know things like birthdates precisely.

Our current practice is to use January for an unknown month, and the 1st for an unknown day, so:

  • If we know you were born in 1950, your birthday is set to 01-01-1950
  • If we know you were born in June of 1950, your birthday is set to 06-01-1950
  • If we know you were born on June 14, 1950, your birthday is set to 06-14-1950

This has the advantage of allowing the data type to be a date, but the problem that you there really are people born on January 1st and June 1st, and we can't tell the difference.

One option would be to set up a second attribute that stores the known level of precision, but that gets messy, both on the list building side and on the data entry side. Especially since there's no way to link two attributes and require that if you have one you have to have the other.

I would really like the attribute to work with the date picking tools on the front end, if at all possible.

If there's no way to do it in an attribute, I'm willing to consider putting it in a custom screen.

Anybody have any brilliant ideas? Anybody done it before?  Thanks!

Parents
  • Maybe I'm not understanding this well enough but why not have different attributes that are able to hold the date and that the attribute name defines the level of precision?  What I mean is:

    Birthdate_ymd - where the year, month and day is known

    Birthdate_ym - where only the year and month are known

    Birthdate_y where only the year is known

    Would the above then not let you follow your existing procedure?

    Martin

  • The problem with this approach is that we would end up with three different attributes to store a single piece of information, so every time we need to query on birthdate we would have to check three separate locations.

    Plus, we would run the risk of ending up with conflicting data, since there's no way to enforce allowing only one attribute out of a set of three. So for instance, we could end up with somebody who has Birthdate_ymd=1950-06-15 AND Birthdate_ym=1955-04-01.

Reply
  • The problem with this approach is that we would end up with three different attributes to store a single piece of information, so every time we need to query on birthdate we would have to check three separate locations.

    Plus, we would run the risk of ending up with conflicting data, since there's no way to enforce allowing only one attribute out of a set of three. So for instance, we could end up with somebody who has Birthdate_ymd=1950-06-15 AND Birthdate_ym=1955-04-01.

Children
No Data