On my system '04:00 doesn't change the timezone string if it is changing the timezone:
$> date -d '04:00'
Tue Jan 19 04:00:00 EST 2016
$> date -d '04:00 today +1 day'
Tue Jan 19 22:00:00 EST 2016
$> date -d '04:00 +1 day'
Tue Jan 19 22:00:00 EST 2016
Also I noticed the format of the Timezone doesn't shift for RFC-2822
zone = (( "+" / "-" ) 4DIGIT) / obs-zone The zone specifies the offset from Coordinated Universal Time (UTC,
formerly referred to as "Greenwich Mean Time") that the date and
time-of-day represent. The "+" or "-" indicates whether the
time-of-day is ahead of (i.e., east of) or behind (i.e., west of)
Universal Time. The first two digits indicate the number of hours
difference from Universal Time, and the last two digits indicate the
number of minutes difference from Universal Time. (Hence, +hhmm
means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
minutes). The form "+0000" SHOULD be used to indicate a time zone at
Universal Time. Though "-0000" also indicates Universal Time, it is
used to indicate that the time was generated on a system that may be
in a local time zone other than Universal Time and therefore
indicates that the date-time contains no information about the local
time zone.
$> date -R
Tue, 19 Jan 2016 10:58:01 -0500
Mon, 18 Jan 2016 22:00:00 -0500
it states:
The time may alternatively be followed by a time zone correction,
expressed as `SHHMM', where S is `+' or `-', HH is a number of zone
hours and MM is a number of zone minutes. The zone minutes term, MM,
may be omitted, in which case the one- or two-digit correction is
interpreted as a number of hours. You can also separate HH from MM
with a colon. When a time zone correction is given this way, it forces
interpretation of the time relative to Coordinated Universal Time
(UTC), overriding any previous specification for the time zone or the
local time zone. For example, `+0530' and `+05:30' both stand for the
time zone 5.5 hours ahead of UTC (e.g., India). This is the best way to
specify a time zone correction by fractional parts of an hour. The
maximum zone correction is 24 hours.
It seems wrong to accept less than a 4 digit TZ correction
according to the info page. Especially since the +1 is followed
by day. I think the logic for this should probably be that if
you are going to be friendly and presume that +1 is a shorthand
timezone shift that you should do so after you have parsed the
date string for more expected syntaxes.