Home > date > If you want to get a future date, why can't you just get the current date and use sed/awk/etc?

If you want to get a future date, why can't you just get the current date and use sed/awk/etc?

September 17Hits:1

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?


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.

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
$ 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

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.


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.


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


Related Articles

Copyright (C) 2017 ceus-now.com, All Rights Reserved. webmaster#ceus-now.com 14 q. 2.482 s.