I think the underlying problem is that "CST" is an ambiguous name for a timezone. It can stand for Central Standard Time, China Standard Time, and Cuba Standard Time.
[me@risby ~]$ export TZ=GMT ; date
Sat 7 Jan 09:21:31 GMT 2017
[me@risby ~]$ export TZ=US/Central ; date
Sat 7 Jan 03:21:31 CST 2017
[me@risby ~]$ export TZ=ROC ; date
Sat 7 Jan 17:21:31 CST 2017
[me@risby ~]$ export TZ=America/Havana ; date
Sat 7 Jan 04:21:31 CST 2017
(I'm aware that the ROC is not the PRC, but they keep the same time, and I can't immediately put my hand on an unambiguously PRC-specific timezone in my
So I suspect you're thinking that your system clock is in China Standard Time, and thus expecting GMT to be eight hours behind that (0748GMT), whereas my guess would be that it is in Central Standard Time, which puts GMT six hours ahead of that (2148GMT). The latter interpretation is consistent with what you've shown us.
So set your system timezone to what you want it to be, preferably using geographical timezones rather than abbreviation-based ones. If the system clock is then wrong, set it (preferably using NTP, which is all UTC-based and doesn't embed any of these problems, and which will keep the clock in sync going forward).