SanfordWhiteman

Not really so hard to build. You just need to use a Forms 2.0 "Lookup Form" which I'm demoed a couple of times. The catch is you can't use program or list membership, but you can use segment membership or any lead field to filter eligibility.

Um, Marketo Forms 2.0 has a robust JavaScript API.

One assumes the Marketo feature will be built the same way, or else it would be a total disaster.

I think what you want (though you may not realize it!) is a server-side forms plugin API into which you could plug other technology.If Marketo were to automatically integrate anything (and they will in the near future), it would be reCAPTCHA. Hence it wouldn't help your case!

You're not considering the engineering cost of developing anything close to Google's solution. No way does Marketo (or any similar entity) have resources to dedicate to this task.

Sure, but why can't they add the form fillout timestamp as a DateTime field? That's the typical way to do it.

I sort of like this Idea, yet sort of not... in some systems it's important to have system mod stamps that you cannot be tempted to use in filters, because they can be unexpectedly reset as side effects of other actions.For example, if you detach and reattach an object (necessary in some workflows) ...

Date times should always be *stored* in UTC. A timezone is used for output, not comparison or storage. Although some buggy systems break this rule, here you're in complete control: your token is UTC, your comparison is to the browser's UTC getTime().

But if you create a single reusable token, they don't have to learn VTL.

It's sort of the opposite, though -- the locale format is person-specific, not instance-wide, as noted here:Localize Date Format in Token (Velocity)