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!
Subscribe to:
Post Comments (Atom)
Fencing
Bit of fun... We usually put up some Christmas lights on the house - some fairy lights on the metal fencing at the front, but a pain as mean...
-
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us... -
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo... -
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...
Why would "tomorrow" on March 30th be the first? (my Debian also says the field you're looking to return is +%d too)...
ReplyDeletejason@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.
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:
ReplyDeleteWhen 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).
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.
DeleteIf 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 :-)
Similar "issues" discussed in this thread: https://lists.lopsa.org/pipermail/tech/2012-May/014680.html
ReplyDeleteThe most pertinent is probably this one: https://lists.lopsa.org/pipermail/tech/2012-May/014688.html
If you need to avoid dst uncertainty, and in most scripts, you should, then use the -u option.
Deletetony@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 :)