Time estimation for successful brute force attack
Passwords are not encrypted they are hashed with proper password hashing algorithms like Scrypt, PBKDF2, or better Argon2, the last is the winner of the 2015 password hashing competition.
I would like to assume that you use one of the above, however, the time that you measured implies the opposite. At least, you used an iteration count as little as possible.
The attackers are not like you - and they will never be - to check a single candidate password one at a time. They like to use as much as possible parallelization. See hashcat as a good example. CPUs, GPUs, ASICs, and FPGAs can be combined to find the target. Simple hashing can be searched massively in parallel even in a single GPU.
Therefore we need to mitigate these attacks as much as possible. The proper password hashing algorithms are memory-hard functions to prevent the massive parallelization and they have iteration count to increase the timing. With these, the attacker's massive parallelization is prevented and the search timing is crippled. Usually, the work factor is adjusted for the user's perspective so that the user does not wait so much for a login. For example, 400K iteration is for PBKDF2 may enough.

I was thinking:

AvrgTimeToEncrypt^PasswordType x PasswordLength ?


Once we forced the attacker to a single run on the single CPU thread, or one in a GPU, etc. we can talk about the timings a bit more precisely.
Let formalize as;

$\mathcal{S}$ as the password space.
$t$ is the execution time of a machine to test a given password hash and candidate from $\mathcal{S}$. (we use a uniform approach here, the timing will be different in a CPU, GPU).
$c$ is the number of machines that the attacker can use.

Now the search time of the space $\mathcal{S}$ is
$$ \frac{|S|}{t \cdot c}$$