If I execute this from console in my Centos 6 server

# date

I receive this

Wed Oct 11 05:11:00 -03 2017

anyone can explain me why date is returning -03 ( an UTC offsets )

instead of this

Tue Oct 10 12:30:50 AMST 2017

How can I do to return the AMST value instead of the numeric value -03 ?

note: Also , if I execute this

# zdump /etc/localtime
/etc/localtime  Wed Oct 11 05:27:33 2017 -03
zdump: warning: zone "/etc/localtime" abbreviation "-03" lacks alphabetic at start 

note2 : using UTC offsets is unexpected by many tools , so I would avoid it, is it possible.

Thank you

1 Answer 1


It looks like the tzdata has, relatively recently, stopped using "invented abbreviations", see for example Red Hat's report on this:

As of tzdata-2016b, a new approach to providing tzdata time zone abbreviations has been implemented for new time zones. When new zones are created tzdata will now use numeric time zone abbreviations like "+03" rather than the earlier naming convention of inventing new abbreviations like "ASTT".

Additionally, as of tzdata-2017a there has been a policy of removal of zone abbreviations where these abbreviations have no official standing and were invented for convenience.

As a result of this change, some tzdata-2016b data entries may cause zic implementations derived from releases of tzdata-2005j through tzdata-2015e to issue warnings. The zdump command may also issue a warning for these new time zones.

This appears to exactly match the behavior you are seeing. I see the same on a Debian system:

$ zdump America/Sao_Paulo UTC
America/Sao_Paulo  Wed Oct 11 11:19:19 2017 -03
zdump: warning: zone "America/Sao_Paulo" abbreviation "-03" lacks alphabetic at start
UTC                Wed Oct 11 14:19:19 2017 UTC

A different system, running with an outdated version of tzdata, shows the "BRT" time zone:

$ zdump America/Sao_Paulo UTC
America/Sao_Paulo  Wed Oct 11 11:19:40 2017 BRT
UTC                Wed Oct 11 14:19:40 2017 UTC

In both cases, the actual local time appears to be correct. The issue is also acknowledged in CentOS.

It looks like your best bet is to not worry about the unexpected zone abbreviation or, if you really care about this and don't care about other time zone updates, you could roll back your tzdata package to a pre-2017a version.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .