Avoiding a small risk of failure in timestamp(tz) regression tests

I noticed a buildfarm failure here:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skate&dt=2019-12-22%2007%3A49%3A22

================== pgsql.build/src/test/regress/regression.diffs ==================
*** /home/pgbf/buildroot/REL_10_STABLE/pgsql.build/src/test/regress/expected/timestamptz.out 2019-12-13 08:51:47.000000000 +0100
--- /home/pgbf/buildroot/REL_10_STABLE/pgsql.build/src/test/regress/results/timestamptz.out 2019-12-22 09:00:00.000000000 +0100
***************
*** 27,33 ****
SELECT count(*) AS One FROM TIMESTAMPTZ_TBL WHERE d1 = timestamp with time zone 'today';
one
-----
! 1
(1 row)

SELECT count(*) AS One FROM TIMESTAMPTZ_TBL WHERE d1 = timestamp with time zone 'tomorrow';
--- 27,33 ----
SELECT count(*) AS One FROM TIMESTAMPTZ_TBL WHERE d1 = timestamp with time zone 'today';
one
-----
! 2
(1 row)

SELECT count(*) AS One FROM TIMESTAMPTZ_TBL WHERE d1 = timestamp with time zone 'tomorrow';

Judging by the reported timestamp on the results file, this is an instance
of the problem mentioned in the comments in timestamptz.sql:

-- NOTE: it is possible for this part of the test to fail if the transaction
-- block is entered exactly at local midnight; then 'now' and 'today' have
-- the same values and the counts will come out different.

On most machines it'd be pretty hard to hit that window; I speculate that
"skate" has got a very low-resolution system clock, making the window
larger. Nonetheless, a test that's got designed-in failure modes is
annoying. We can dodge this by separating the test for "now" from the
tests for the today/tomorrow/etc input strings, as attached.
Any objections?

regards, tom lane