34

Today my clock was automatically adjusted to summer time, and a script from a crontab started failing. I had a look at what was happening, and the following error was being displayed, with LC_ALL=C:

date: invalid date '2016-10-16'

I though it would be best just to reboot the system, but now I have rebooted, and the error still appears:

$ date -d '2016-10-15'
Sat Oct 15 00:00:00 BRT 2016
$ date -d '2016-10-16'
date: data inválida “2016-10-16”
$ date -d '2016-10-17'
Mon Oct 17 00:00:00 BRST 2016

What could be causing this?

Peter Mortensen
  • 1,029
  • 1
  • 8
  • 10
admirabilis
  • 4,642
  • 9
  • 41
  • 57
  • What OS are you running this command from? Cannot reproduce on Debian 8. Tried with two different `locale`s: `sv_SE.utf8` and `en_us.utf-8`. – maulinglawns Oct 16 '16 at 08:06
  • 2
    At what time of the day (night) does Brazil forward the clocks to summer time? – techraf Oct 16 '16 at 08:33
  • I though all countries where shifting at a late time, like 2 in the morning, where it is less likely to cause issues. – njzk2 Oct 17 '16 at 15:58

1 Answers1

56

The problem is the daylight saving time changed and forwarded 1 hour, on 16 October 2016 in your timezone:

$ zdump -v America/Sao_Paulo | awk '/Oct 16/ && /2016/'
America/Sao_Paulo  Sun Oct 16 02:59:59 2016 UTC = Sat Oct 15 23:59:59 2016 BRT isdst=0
America/Sao_Paulo  Sun Oct 16 03:00:00 2016 UTC = Sun Oct 16 01:00:00 2016 BRST isdst=1

So any time between 00:00 to 00:59 on that day is considered invalid in your timezone (but maybe valid in others):

$ TZ=America/Sao_Paulo gdate -d '2016-10-16 0:59'
gdate: invalid date ‘2016-10-16 0:59’

$ TZ=Asia/Ho_Chi_Minh gdate -d '2016-10-16 0:59'
Sun Oct 16 00:59:00 ICT 2016

You can set additional time, which isn't in that range:

$ TZ=America/Sao_Paulo gdate -d '2016-10-16 1:00'
Sun Oct 16 01:00:00 BRST 2016

The above is GNU date behavior.

BSD date does not have this problem. If the input date is invalid in the timezone, it will be silently adjusted forwards 1 hour until it reaches a valid time:

$ TZ=America/Sao_Paulo date -j -f '%Y%m%d%H%M' 201610160000
Sun Oct 16 01:00:53 BRST 2016
cuonglm
  • 150,973
  • 38
  • 327
  • 406
  • 1 hour and 53 seconds?! – domen Oct 17 '16 at 12:17
  • So it adjusted the time by 53 seconds too far into the future? Or did I misunderstand something? – domen Oct 17 '16 at 12:45
  • 1
    Aah, makes sense; preserves the non-specified data (as opposed to clearing). Still a bit strange as adjusting forward by 00:59:07 would be enough in this case. – domen Oct 17 '16 at 13:06
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/46921/discussion-between-domen-and-cuonglm). – domen Oct 17 '16 at 13:08