CAPWATCH Data - DOB wrong?

Started by a2capt, January 21, 2014, 03:03:47 AM

0 Members and 1 Guest are viewing this topic.

a2capt

Looking at CAPWATCH data .. every DoB value is the 1st of the month. WTF?

Spaceman3750

Quote from: a2capt on January 21, 2014, 03:03:47 AM
Looking at CAPWATCH data .. every DoB value is the 1st of the month. WTF?

Do you have rights to see the exact DOB? Some people just get the "Over 18" and "over 21" views, while others get an exact DOB. For example, in the Personnel Information app, I can see exact DOB.

Eclipse

Wow.  Confirmed I see it too - I checked my own.  The month and year are correct, but date shows "1".

Is that something a member can even change themselves?

The pull down scrolls in eservices have been wonky lately, too.

"That Others May Zoom"

Panache

My DOB is correct.

Maybe the overload of comments for the draft 39-1 finally drove eServices over the edge.

a2capt

If you look at your own record, it is correct. If you export a dump they're all the first of the month. This came up because I'm putting together an MSA, and I thought rather than harvest it all from 70 Form 31's, I'd get it all from the download.


Bzzzzzzt.

NIN

Yet another change to the data product used in the field?
Darin Ninness, Col, CAP
I have no responsibilities whatsoever
I like to have Difficult Adult Conversations™
The contents of this post are Copyright © 2007-2024 by NIN. All rights are reserved. Specific permission is given to quote this post here on CAP-Talk only.

dwb

I noticed this quite some time ago. For CAPWATCH downloads, you're apparently only authorized to see month and year of birth. So the date is always 1 (plot twist: some people were born on the first of the month).

NIN

Quote from: dwb on January 21, 2014, 12:22:47 PM
I noticed this quite some time ago. For CAPWATCH downloads, you're apparently only authorized to see month and year of birth. So the date is always 1 (plot twist: some people were born on the first of the month).

I see what you did there. The old CAPTalk switcheroo
Darin Ninness, Col, CAP
I have no responsibilities whatsoever
I like to have Difficult Adult Conversations™
The contents of this post are Copyright © 2007-2024 by NIN. All rights are reserved. Specific permission is given to quote this post here on CAP-Talk only.

a2capt

The last time I actually used the data at that level for something useful, it was correct. So for purposes of age determination, if you're not in the same calendar month it's fine, if you are .. seek official data at the event for sure.

JeffDG

Quote from: a2capt on January 21, 2014, 04:26:49 PM
The last time I actually used the data at that level for something useful, it was correct. So for purposes of age determination, if you're not in the same calendar month it's fine, if you are .. seek official data at the event for sure.
So much for using birthday as a "validation" question for password resets.

dwb

NHQ is still storing the whole birthday. It's just that they're not giving you access to the day in the download (for whatever reason). So password resets still work.

JeffDG

Quote from: dwb on January 21, 2014, 07:13:27 PM
NHQ is still storing the whole birthday. It's just that they're not giving you access to the day in the download (for whatever reason). So password resets still work.
Well, NHQ also won't do OAuth or any other kind of authentication, so my wing website has to have a whole different username/password for everyone in the wing for it.

So, yes, I have to remove birthdate from the password reset verification process.

a2capt

Hmmm.. I wonder if it's available in an IMU DB.. which I do have a way to break down to CSV as well. Plenty of reasons you'd want to know the exact day in an ES environment. Including that it uses that to login.

I should have titled the thread "DoB incomplete?" .. or obfuscated.

JeffDG

Quote from: a2capt on January 21, 2014, 07:40:12 PM
Hmmm.. I wonder if it's available in an IMU DB.. which I do have a way to break down to CSV as well. Plenty of reasons you'd want to know the exact day in an ES environment. Including that it uses that to login.

I should have titled the thread "DoB incomplete?" .. or obfuscated.
I'll have to look when I get home tonight...still doesn't help much, whole process for the website is very automated...although, maybe I could get Pete to let me access the IMU SQL tables that I helped him migrate to a while back, I could do an SSIS package to get the data I need.

What bugs me is that this is yet another change that NHQ has made recently without notification to people who use it, like the ID card barcodes.

Tim Medeiros

This has actually been the case for at least a year (I want to say quite a bit longer than that actually but I know at least a year).
TIMOTHY R. MEDEIROS, Lt Col, CAP
Chair, National IT Functional User Group
1577/2811

a2capt

Seems like just before this time last year, when I was putting together an MSA I didn't have this problem. I didn't even notice it at first this time around, and honestly, got about 1/4 of the way in of picking out lines from the members table that I realized.. WTF!? everyone I have on staff is born in January!  .. because the import I did also did a trip up and folded the 1st as the month and the month 1-12 as the day. So I didn't notice at first. That was it's own "what the.. " revelation.  Then I saw that everything was the 1st.

So I went back into archives and found real data but not from any current download. 

NIN

Quote from: JeffDG on January 21, 2014, 07:44:07 PM
What bugs me is that this is yet another change that NHQ has made recently without notification to people who use it, like the ID card barcodes.

Won't be a big deal until someone winds up having changed an age bracket (think of how we talk about over/under 18 for federal coverage) and nobody noticed because their it looks like they're over 18, supposedly as of the 1st of the month, and they're really not, and they get injured or killed and we find out they're not covered for federal insurance

Whoops.

Then its going to be the field's fault for relying on that data.

(the day-to-day corallary might be getting flagged a little early that a cadet is due for his "adult CPPT briefing," but because he's not actually 18 yet, you can't put the completion in until after his actual birthday.  Thats a minor issue, but it could become a paperwork chase when the PDO does the training, can't put the completion into eServices the day after he does it, and then forgets to do it after poor Timmy's actual 18th birthday...)



Darin Ninness, Col, CAP
I have no responsibilities whatsoever
I like to have Difficult Adult Conversations™
The contents of this post are Copyright © 2007-2024 by NIN. All rights are reserved. Specific permission is given to quote this post here on CAP-Talk only.

SarDragon

Cppt completions can be entered at 17 1/2, IRRC. That changed when 17 yo cadets were allowed to take CPPT.
Dave Bowles
Maj, CAP
AT1, USN Retired
50 Year Member
Mitchell Award (unnumbered)
C/WO, CAP, Ret

NIN

Quote from: SarDragon on January 23, 2014, 08:41:14 AM
Cppt completions can be entered at 17 1/2, IRRC. That changed when 17 yo cadets were allowed to take CPPT.

Oooh, missed that change (must have happened when I was on sabbatical..)
Darin Ninness, Col, CAP
I have no responsibilities whatsoever
I like to have Difficult Adult Conversations™
The contents of this post are Copyright © 2007-2024 by NIN. All rights are reserved. Specific permission is given to quote this post here on CAP-Talk only.

cm42

The larger problem is CPFT. It will create errors for cadets who are in their birth month, as all ages <18 change required passing scores with each change in age, so you'll end up asking cadets to meet requirements for an age which they haven't reached yet. >:(

The actual birth day of month is in the restricted personnel info (and is on the CAPF15 that should be on hand at the squadron), but it's a pretty big inconvenience to have to check for it once they get into CAPWATCH and imported into SIMS so the CPFT report will be correct. I haven't checked to see if the CPFT report in eServices is correct....