additional empty lines?

Removed extra lines at end of file.

It seems $observedIdList -contains $oneExpectedId | Should Be $true was good.

It seems $observedIdList -contains $oneExpectedId | Should Be $true was good.

IT (@it) seems Get-Random isn't good for tests. Maybe cycle for all $TimeZonesAvailable is better and then we can remove next test.

On a typical Ubuntu 16.04 machine there are 424 time zones. Checking for all time zones does not provide additional value to the test, but increases test execution time.

Though Get-Random picks a different time zone when the test is run, Pester will show what the expected output was, and what the actual output is. So, debugging or reproducing the failure should not be a problem. Your thoughts?

The next test uses multiple time zone IDs for the -Id parameter, hence it is a different test.

Ilya (@iSazonov) let me know what you think?

I think the tests should be deterministic and I would prefer don't use Get-Random because this reproducibly in manual locally but not in CI restart.
Perhaps it makes no sense to test all zones but it is very simple and very fast - I believe we may not worry about it here. (Although we may be limited to some selected time zone names/ids.)

Ilya (@iSazonov) I agree on tests being deterministic. Though it seems like a small increase in execution time (from 80ms to 780ms on my machine), it eventually adds up. Since it does not provide additional coverage, I do not think we should go through all of them.

I cannot use names / IDs because there is no guarantee that the time zone is available on the machine. Time zone names/IDs are different of different operating systems. Example:

 Get-TimeZone -Name Pacific* | Select-Object -ExpandProperty Id

It has different output in Windows v/s Ubuntu.

I cannot use Select-Object -First 3, as there is no guarantee that the system has 3 time zones.

What do you think?

Maybe create three separated "testcases" - for Windows, Linux and Mac?

I think a reasonable test would be that if you get multiple timezones, check the first n (no need for random sample) and the break out of the test. No need to check them all.
FWIW, this is still not deterministic because it relies on what is installed which may change across systems, and may not even satisfy the CI restart scenario if the config changes

The same about Get-Random.

The same about Get-Random.

The same about Get-Random.

Get-Random [](start = 27, length = 10)

also, if you're going to use get-random, it might be more efficient to do:
get-random -input (1..$TimeZonesAvailable.Count) -count 3

$TimeZonesAvailable | Select-Object -Index ((Get-Random) % $TimeZonesAvailable.Count) [](start = 22, length = 85)

$TimeZonesAvailable[(Get-Random -max ($TimeZonesAvailable.Count +1))] avoids a pipeline

Please retain the original character. This unintentional change is usually done by VSCode.

Fixed.

Would this test work if [System.TimeZoneInfo]::GetSystemTimeZones().Count -eq 0? If not, then it should also be skipped in that case, like what you do for Describe "Get-Timezone test cases.

Fixed. Moved it to the same Describe.

In what case would $TimeZonesAvailable.Count -eq 0 be true?

If the tzdata package is removed.

good to know. Thanks

When it looks the same but git shows a diff, it's usually due to a special character change. What I would do in this case is to first revert changes to this file (git checkout), and then open it in a different editor (not vscode), and make the Get-TimeZone change.
Ilya (@iSazonov) do you happen to know if there is any configuration file we can use to prevent VSCode from messing up special characters?