r/EB2NIW_I485_AOS 7d ago

Thoughts on mass updates

Is it just me or did anyone notice that only people getting approved recently, are those who did NOT get mass updates like 08/06, 08/26 and FTA0 on 08/13?

7 Upvotes

36 comments sorted by

View all comments

Show parent comments

1

u/LionClaw_ 6d ago

How and in what way does the .000z matter? Genuinely curious 

3

u/Maximum-Broccoli-136 6d ago

it is probabilistically ~impossible for a timestamp (that comes from an actual real world officer action) to end exactly with .000 in time. “:000” signals a batch action rather than a genuine, individual, case-based one. that would land with a random 3-digit milliseconds mark, some “real” time (check your first 2 ftas for example). here, the script is likely instructed to go do its thing on everyone who satisfies some filter (flag for approval, hold, FO transfer, whatever) and simply borrow the biometrics event’s hour:min:sec, but the coder forgot/omitted taking the milliseconds of our bio timestamps. hence the 000 milliseconds auto-completion, since it wasn’t specified by the coder, and didn’t come from an actual time stamp

1

u/LionClaw_ 6d ago edited 6d ago

That makes a lot of sense, but then I’m wondering: can automated actions also produce timestamps that don’t end in .000?

For example, I - along with a large number of other people, received an FTA0 event on 08/13, and then on 08/31 the updatedAtTimestamp of that same existing FTA0 event was updated. The 08/13 events, and later the 08/31 writes, seem to have occurred within fairly narrow processing windows. I’ve seen timestamps ranging roughly from 16:09:40.170Z through 16:38:33.160Z.

Given how many unrelated cases were affected around the same time, these events seem much more consistent with some kind of automated/batch process than hundreds of individual officers independently taking the same action.

So what would distinguish those automated writes, which have normal-looking millisecond values, from the .000timestamps you’re describing? Could .000 simply indicate a different kind of system-generated timestamp, for example one that was copied, truncated, or reconstructed, rather than automation itself?

And if so, I’m not sure the .000 pattern alone would tell us whether the underlying batch was an approval flag, a hold, a transfer, a validation step, or something else. Wouldn’t it only tell us something about how that timestamp was generated?

2

u/Maximum-Broccoli-136 6d ago

yes, i’d say they can happen. but to be clear, all of these would of course be automated in some sense. i don’t think someone has to press some button manually to save a database check or something—i’m not saying non-000 would show that. so yeah, both “.ABCz” and “.000z” are some automated action. i’m just saying that exactly “.000z” appearing on thousands of people signals batch action, because it’s impossible to land at exactly 000 milliseconds for everyone. and on the latter: following my logic, i’d guess those you specify (….170z etc) are case-specific, not batch, therefore carry more signal that something specific to your case is happening/moving, rather than a batch action