Indeed this is really strange… It seems to be an issue in gdate, specific to High Sierra, at least I couldn’t reproduce it on Mojave, but it happens on every High Sierra config even with the latest coreutils available in brew
If you check the date that fails, 2019 Aug 05, that’s not in PST (Pacific Standard Time) but in PDT (Pacific Daylight Time) timezone, that is in the summertime/daylight saving time. The other date is actually in PST, that’s why it doesn’t return an error, but Aug 05 2019 technically will be in PDT and not PST.
Again, why it does not return an error on Mojave, my best guess is there’s some difference in the High Sierra vs Mojave gdate versions that can be installed from brew.
One solution could be to use UTC as that does not have a daylight saving counterpart, for the one that has (e.g. PST <-> PDT) the High Sierra gdate expects the right one for the date.
You can set timezone with systemsetup -settimezone <tz>. For a list of valid <tz> values, see systemsetup -listtimezones.
However, I’m not sure if setting the system timezone would help. If I understand your setup correctly, PlistBuddy reads these date strings from files you provide and gdate fails to process specific strings, because the date encoded in the string does not exist in the given timezone in the string itself.
Thus, whatever you set your timezone, the same issue would occur.