bug#15927: Bug in date command

[Bob Proulx]

tag 15927 - moreinfo + notabug
close 15927
thanks

Hello Claudio,

Please keep the bug log in the recipient list.  That way others in the
team on the mailing list can participate in the discussion.

Claudio Pinto wrote:
> Current default time zone: 'America/Sao_Paulo'
> Local time is now:      Ter Nov 19 17:10:40 BRST 2013.
> Universal Time is now:  Tue Nov 19 19:10:40 UTC 2013.
>
> Here in Brazil we have the time in an hour early.

Yes.  And that is the problem.  The time you have specified does not
exist.  That is what makes it an invalid time.

  $ zdump -v America/Sao_Paulo | grep Oct.*2013
  America/Sao_Paulo  Sun Oct 20 02:59:59 2013 UTC = Sat Oct 19 23:59:59 2013 
BRT isdst=0 gmtoff=-10800
  America/Sao_Paulo  Sun Oct 20 03:00:00 2013 UTC = Sun Oct 20 01:00:00 2013 
BRST isdst=1 gmtoff=-7200

In the America/Sao_Paulo timezone as shown above the seconds of the
clock tick to "Oct 19 23:59:59 2013 BRT" and the very next tick of the
clock is "Sun Oct 20 01:00:00 2013 BRST".  But you are asking for
"Sun Oct 20 00:00:00" which does not exist in either BRT or BRST.

Note that this is not a technology issue.  This is an issue of
changing the clock for Daylight Saving Time.  Most countries do this
by an act of government.

> Removing a difference an hour, with the command below, the error does not
> happen ...
> date --date="10/20/2013 01:00"
> with the command below error appears:
> date --date="10/20/2013 00:59"

Correct.  Because those are invalid according to your
America/Sao_Paulo timezone.  To avoid those errors either use UTC
which does not change for Daylight Saving Time or use 12:00 noon to
avoid being near the time that it changes.

Since this is a bug in usage and not a bug in the date calculations I
am going to close the bug report.  However if things are still not
clear please feel free to follow up with any responses or comments and
we can keep discussing it.

Please keep the bug log address in the recipient list.

Bob