You have two possible situations here.
Case A: you are outside the RunWithElevatedPrivileges scope
you may be getting an elevated SPWeb instance that has been saved OUTSIDE the scope of the RunWithElevatedPrivileges delegate. This is a code horror in most cases, but it is still possible.
In this case, recreating a new instance based on the url of the elevated one would be enough: the new instance won't be elevated, so you can get your user from there.
Case B: you method is called inside a RunWithElevatedPrivileges delegate
In this case recreating the SPWeb instance won't do you any good. Any new instance would still be elevated, so this is a no go.
To escape this situation, you need to find an instance that was created outside the elevation scope. How? By exploiting your execution context: for example, in an feature event receiver you could access the web instance in the event properties etc. Since you are in a custom method and you cannot alter the received parameters, you need to access some sort of context. Could you resort to SPContext.Current.Web? That instance isn't elevated, so the user should be the current one browsing the site. That said, you may be in a situation where the context is invalid/null, in which case AFAIK there is no way to obtain the original user from the elevated instance: you will need to store it somewhere (tip: a static singleton?) before entering the elevation context.
What to do if your method is called inside a RunWithElevatedPrivileges delegate but you are unsure of having a valid SPContext? This is only a very wild guess, but let's think about it.
RunWithElevatedPrivileges will revert to the application pool identity, right? If there isn't an application pool it would mean that there is no app pool identity, so the current user outside and inside the delegate should be the same. If there is an app pool, most time you will have an SPContex, which is unelevated by definition. There are also some specific case where you run in timer jobs and such and the context is null: in that case I believe that you are using the app pool identity anyway, so again, run with elevated should have no effect.
Based on this it would seems that your best bet is to use the user from the SPContex when possible, and assume the elevated and unelevated user to be the same when the context is null.
Take that with a grain of salt though...