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 $> date -R -d'04:00 +1' Mon, 18 Jan 2016 22:00:00 -0500 Also is it documented that +[0-9] does a timezone shift? On the man page, I saw it stipulate using the environment variable TZ and in the info page 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. On Mon, Jan 18, 2016 at 9:16 AM, Pádraig Brady <[email protected]> wrote: > tag 22397 notabug > close > > On 18/01/16 03:53, Adam Danischewski wrote: > > $> date > > Sun Jan 17 22:49:40 EST 2016 > > $> date -d"04:00" > > Sun Jan 17 04:00:00 EST 2016 > > $> date -d"04:00 +1 day" > > Sun Jan 17 22:00:00 EST 2016 > > > > To fix this, a work around for me now is: > > $> date -d"$(date -d"04:00") +1 day" > > Mon Jan 18 04:00:00 EST 2016 > > The +1 is taken as a timezone offset. > You'll want: > > date -d '04:00 today +1 day' > > Note also the relative date discussion at: > http://bugs.gnu.org/18159 > > cheers, > Pádraig. >
