Why the Execute Aroud idiom is not considered a Strategy design pattern?

More and more I see new labels for the same solutions but with different names. In this case why we cannot simply say that the Execute Aroud idiom is the same that the Strategy design pattern?

When I read the Jon Skeet’s answer to the question: “What is the “Execute Around” idiom?”, he states that:

it's the pattern where you write a method to do things which are always required, e.g. resource allocation and clean-up, and make the caller pass in "what we want to do with the resource".

In this case Jon Skeet uses a executeWithFile(String filename, InputStreamAction action) method as an example of the method that does things which are always required and the interface InputStreamAction as an abstraction over what we want to do with the resource.

  public interface InputStreamAction
  {
      void useStream(InputStream stream) throws IOException;
  }

Comparing this with the Stratey design pattern why we cannot just say that the interface InputStreamAction defines a family of algorithms? And, each implementation of the interface InputStreamAction corresponds to a concrete strategy encapsulating an algorithm. Finally these algorithms are interchangeable and we can make use of the executeWithFile with any of those strategies.

So, why can’t I interpret the Jon Skeet’s answer as an example of the application of the Stratey design pattern?

By the way, which of the idioms came first? The Execute Around or the Strategy design pattern?