0

I've just looked at this question. The first answer states how to get a future date directly from the date command. Why couldn't you just use text manipulation to increment the date? Basically:

date | # increment the time string by some amount here

I'm not familiar with awk or sed or I'd give a better example.

Edit: so basically there is no technical reason? Just portability and the fact that it's harder than it looks?

  • 2
    You could work a string, but since many time utilities like this use seconds as a fundamental unit (and FYI: get their information from the system in terms of seconds elapsed), if you can get your head around 3600 seconds = 1 hour, 86400 seconds = 24 hours, then it is simpler to work with an integer than to do complex string manipulation. – goldilocks Sep 17 '13 at 2:35
  • 2
    There is no technical reason more important than "That's too hard"! Why would you want to chose the hard way to do something if there is an easy one that is more efficient? – terdon Sep 17 '13 at 3:10
  • @terdon obviously I'd just use the date function. This is a theoretical question, not a practical one. – strugee Sep 17 '13 at 3:12
  • Ah, then no, it's just a pain to do with string manipulation. – terdon Sep 17 '13 at 3:14
  • 2
3

Basically, you can, but is not portable enough, can fail and it is more effort at the end of the day.

Let say I want to use awk to increment the minutes by 3. (I will ignore that if it's greater than 59 I have to reset to 00 for now):

$ date
Mon Sep 16 22:52:42 AST 2013
$ date | awk -F: '{printf $1 ":" ; printf $2+3 ":" ; print $3}'
Mon Sep 16 22:55:43 AST 2013

Nice there. But now I have to develop a function that whenever minutes reach 59 it resets to 00. Not nice anymore. Hence is preferred natural ways to increment the time instead of parsing the text.

  • 1
    It is portable (just remember to use a locale-independent date format or set LC_TIME=C). But it is extremely hard to get right once timezones start getting involved, and most programmers get it wrong even when only dates are at stake (raise hands who hasn't seen programs that treat 2000 as a non-leap year or 2100 as a leap year). – Gilles Sep 17 '13 at 21:35
  • For that I said "portable enough" meaning that you have to workaround expected (and unexpected) situations. – Braiam Sep 17 '13 at 22:05
6

You can but it gets complex. If you have a date in simple seconds, for example the seconds that have elapsed since midnight of Thursday, 1 January 1970 (POSIX time), it is relatively easy to add a minute to it:

$ date +%s
1379385111
$ date +%s | awk '{print "Current time is",$1,"soon will be", $1+60}'
Current time is 1379385275 soon will be 1379385335

Well and good, but what if you want to do this with human readable times? What if you want to add 4 months and 2 weeks? Calculating that in seconds is a pain and interpreting such a date is not easy either. For example, what date does 411174000 represent1?

How would you increment Sun 12 Dec 1936 by, say, 3 weeks? It is a surprisingly thorny problem if you're not allowed to use date manipulation libraries. Think about converting all dates to seconds and then adding, bear in mind that some months have 30 days, others 31, let alone February and the leap years. It really is not a trivial problem. That's why most programing languages have date manipulation libraries (Perl for example, or C).

On top of this, date can deal with dates like tomorrow or Oct 18 2017 and can add and subtract them and return a human readable date instead of a string of digits.

Since the standard date program makes this so much easier why should we go and reinvent the wheel?

1 It's Wed Jan 12 00:00:00 CET 1983

5

Manipulating times and dates with anything other than a well thought-out library is just a bad idea. What would appear to be a trivial problem can quickly turn into one of major complexity with issues such as day light savings time, leap years, leap seconds, time zones etc.

Programmers continually think, "Oh I can just do a quick function or two to do this", and you don't have to look back too far to a recent incident where the Apple developers thought this, and hadn't properly dealt with the day light savings transitions properly.

excerpt

The Day Light Savings (DST) started in the US few hours back when the clocks moved forward from 1:59 am to 3:00 am.

However, some iPhone users are reporting all sorts of problems with the DST changes.

TUAW reports:

Several readers report that rather than jumping forward an hour last night as expected, their iPhone clocks actually shifted in the wrong direction — back an hour — because the automatic time zone adjustment went wonky. A reader in Nashville has a phone that thinks he’s in Mountain Time; a reader in Florida’s phone is convinced it should be on Chicago time. Our colleague Mel Martin lives in Arizona, which mostly does not observe DST at all; nevertheless, his phone (which had automatic time zone settings & location settings on) incorrectly jumped forward one hour.

BOTTOM LINE

Don't be tempted by a problem's apparent simplicity, use a library!

  • Except if it's jQuery! D: – Braiam Sep 17 '13 at 3:25

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.