How to get yesterday's date accurately using ksh?

At the time of running following commands my Unix system's time for eastern day light savings was --> 201104210003(yyyymmddHHSS)

 
# This seem to be more accurate.. 
$> echo $(TZ=$(date +%Z)+28 date +%Y%m%d%H%M)
201104200003
 
# This was constructed from old posts from this forum to find Yesterday's date. 
$> echo $(TZ=$(date +%Z)+24 date +%Y%m%d%H%M)
201104200403
 
$> echo $(date +%Z)      
EDT

Can someone tell what would be the 100% accurate solution that takes daylight savings also into account using ksh.

Preferrably still using one line solution.

I also do not fully understand what exactly above code solution is doing, if at all it can be still used!? I allways thought +24 is good, why do I need to use +28 !?

Try this...

/usr/ahamed-> date
Mon Dec 20 02:51:14 CST 2010
/usr/ahamed-> date +%G%m%d%H%M
201012200251
/usr/ahamed-> date +%G%m%d%H%M --date="yesterday"
201012190251

OS : Fedora 13

regards,
Ahamed

Ahmed,
We have Solaris 8. Its not recognizing --date="yesterday".

 
 
$> date +%G%m%d%H%M
201104210750

$> date +%G%m%d%H%M --date="yesterday"
201104210751

Search the forum threads (look into the FAQ section in particular) - this question has been asked and answered numerous times.

vgersh99,

I did lot of searching and read lot of postings about this on this site and finally decided to use my own improved syntax
---> $(TZ=$(date +%Z)+24 date +%Y%m%d%H%M)

But I found a bug with this,, apparently this is putting yesterday's datetime 4 hrs ahead of what its supposed to be.

Please be patient and validate what I found. This is really important for scheduling jobs I am sure for many of us using older shells. I think its worth re-validating it.

Unless you print Hours and minutes you will not know what this is giving is true or not. Or test this after 10 PM.

To be honest, you might have to use perl to do it any better:

perl -MPOSIX -e 'print POSIX::strftime("%Y%m%d%H%M\n", localtime(time-86400));'

cambridge,
That is incredible. Your solution is not only 100% correct, it also formats it.

I am still looking for a reason why the ksh syntax that almost everyone said is working in so many previous posts puts time 4 hrs ahead with "$(TZ=$(date +%Z)+24 date +%Y%m%d%H%M)" and works with " echo $(TZ=$(date +%Z)+28 date +%Y%m%d%H%M)" syntax.

Once again, check out the posted link to the FAQ session - no need to reinvent the wheel (as it will most likely come out squared).

Glad to be of service.

I personally wouldn't choose to modify the TZ variable in order to do date manipulation, because it's not so easy for others to understand your code in the future. However, you can do more background reading here: TZ Variable - The GNU C Library

Even though "echo $(date +%Z)" is giving "EDT", using it to derive datetime is resulting a GMT datetime.

 
echo $(TZ=$(date +%Z)+24 date +%Y%m%d%H%M)

How can we correct above statement to give US Eastern Daylight savings aware datetime?

Following works as a stand alone.., but I could not substitute it with %Z and add +24 to it.

 
$> export TZ="America/New_York"; echo $(date +%TZ)

That "+24" construct is not portable and that's why it's biting you. If you read that FAQ article, I point out the non-portability of this technique. But the idea that the authors of this technique were shooting for was to add 24 to the offset already used by the timezone software. It appears that you are overriding your value rather than modifying it. Rather than screwing around with this troublesome contruct, why not just use one the reasonable solutions that have been offered?

wow, Looks like I am offending too many people here.. I will stop asking more questions on this topic.

Regarding your offset, this may give you some ideas:

or

Thanks a lot ctsgnb, I will stop looking for a one liner solution for this using ksh/bash.

The main idea of the thread mentionned above is to first calculate your offset to make reliable the calculation of the yesterday date based on the timezone and taking into account that offset.
So that the yesterday date is accurrate.