Monday, 1 April 2013

April fool date command

Why does the linux date command not understand tomorrow or yesterday properly.

A script run at 23:00 on 30th March checked date -dtomorrow +%k was 01 to confirm it is running on last day of the month, but the damn date command just adds 24 hours, instead of getting to same time the next day, resulting in just after 00:00 on 1st April. The same script then ran 23:00 on 31st and ran again...

A script ran around 00:30 this morning that creates a directory based on date -dyesterday again got the wrong day...

Both scripts being fixed. But really... Arrrrrrg!

5 comments:

  1. Why would "tomorrow" on March 30th be the first? (my Debian also says the field you're looking to return is +%d too)...

    jason@hogwarts:~$ date
    Mon Apr 1 14:49:42 BST 2013
    $ date -dtomorrow +%d
    02
    $ date -dyesterday +%d
    31
    $ date
    Mon Apr 1 14:50:04 BST 2013
    $

    Naturally I can see how it would fall over when the clocks are pointlessly changed twice per year.

    ReplyDelete
  2. Sorry, that's what 'tomorrow' is defined to do: this is a feature, not a bug. It respects timezones. It means 24 actual physical hours. From coreutils.info:


    When a relative item causes the resulting date to cross a boundary
    where the clocks were adjusted, typically for daylight saving time, the
    resulting date and time are adjusted accordingly.

    If you want to not apply daylight savings adjustments, set TZ to a timezone that has no daylight savings (like UTC).

    ReplyDelete
    Replies
    1. That can be misread - I would consider "Adjusted accordingly" to mean that 1pm GMT + 1 day is 1pm BST, i.e. not 2pm, but adjusted to be 1 day.

      If I had said -d"24 hours" then yes, add 24 hours, but saying "1 day" or "tomorrow" really should do what it says, else why have English parsing for such things in the first place.

      Its a "design bug" not a feature :-)

      Delete
  3. Similar "issues" discussed in this thread: https://lists.lopsa.org/pipermail/tech/2012-May/014680.html
    The most pertinent is probably this one: https://lists.lopsa.org/pipermail/tech/2012-May/014688.html

    ReplyDelete
    Replies
    1. If you need to avoid dst uncertainty, and in most scripts, you should, then use the -u option.

      tony@tony-lx:~$ date
      Wed Apr 3 11:37:45 BST 2013

      tony@tony-lx:~$ date -u
      Wed Apr 3 10:37:52 UTC 2013

      tony@tony-lx:~$ date -dtomorrow +%k
      11

      tony@tony-lx:~$ date -dtomorrow +%k -u
      10

      Plan B is to yse PERL; I think you're expecting too much from bash.
      Then again, I understand your frustration :)

      Delete