Seriously? I think the latter is a lot less scary in a lot of ways, and it contains a very specific identifier even if multiple things were happening at once. It also has built-in error correction in case the user reporting the error mis-reads one digit or something that "isn't important". And time zones in the identifier are just begging for misconfiguration problems.

Don't forget that the error phrase is not seen in a total vacuum. It is prepended with the sentence "If you contact us about this error, here is your unique error phrase", which even un-savvy users will recognise as a password (in the children's "what's the password?" sense), that they need to remember exactly and that doesn't itself directly carry information.

On the other hand, if you print out the date/time as part of the error message, the user is just going to glance at it, say, yup that's the current time, and then totally fail to record it (because there's no new information there, right?) or even worse, try to remember it and end up guessing at the time or even the date, making it almost worse than nothing.

you don't report anything to the user other than you're issue has been logged, when cust service looks up the user account they'll be able to pick out incidents themselves and verify with the user.

"Hello Bob, I see you have 4 incidents today that we've logged, are you calling about the issue with the Dashboard page?"

Hmm, I hope none of your users ever have login issues.

thanks!

I agree. This weird phrase is still an exposed 'system code'. There still is no reason to expose a system code, no matter how cute.

If you've managed to log the error and displayed a payment page, you are in a good enough state to automatically send an email and/or file a ticket. You can refer to the ticket since that is the actionable object.