35

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?

  • What OS are you running this command from? Cannot reproduce on Debian 8. Tried with two different locales: sv_SE.utf8 and en_us.utf-8. – maulinglawns Oct 16 '16 at 8:06
  • 2
    At what time of the day (night) does Brazil forward the clocks to summer time? – techraf Oct 16 '16 at 8: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
57

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
  • 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. – domen Oct 17 '16 at 13:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.