I had to do this in the past with brute force parsing and calculation in shell script.
Doing it manually in shell script is highly error-prone and slow. You need to account for days per month, leap years, time zones. It will fail with different locales and different languages.
I fixed up one of my old scripts, this would probably need to be modified for different shell environments, but there shouldn't be anything that can't be changed to work in any shell.
#!/bin/sh
datestring="Nov 28 20:27:19 2012 GMT"
today=`date`
function date2epoch {
month=$1
day=$2
time=$3
year=$4
zone=$5
# assume 365 day years
epochtime=$(( (year-1970) * 365 * 24 * 60 * 60 ))
# adjust for leap days
i=1970
while [[ $i -lt $4 ]]
do
if [[ 0 -eq $(( i % 400 )) ]]
then
#echo $i is a leap year
# divisible by 400 is a leap year
epochtime=$((epochtime+24*60*60))
elif [[ 0 -eq $(( i % 100 )) ]]
then
#echo $i is not a leap year
epochtime=$epochtime
elif [[ 0 -eq $(( i % 4 )) ]]
then
#echo $i is a leap year
# divisible by 4 is a leap year
epochtime=$((epochtime+24*60*60))
# epoch=`expr $epoch + 24 * 60 * 60`
fi
i=$((i+1))
done
dayofyear=0
for imonth in Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
do
if [[ $month == $imonth ]]
then
break
fi
case $imonth in
'Feb')
if [[ 0 -eq $(( year % 400 )) ]]
then
days=29
elif [[ 0 -eq $(( year % 100 )) ]]
then
days=28
elif [[ 0 -eq $(( year % 4 )) ]]
then
days=29
fi
;;
Jan|Mar|May|Jul|Aug|Oct|Dec) days=31 ;;
*) days=30 ;;
esac
#echo $imonth has $days days
dayofyear=$((dayofyear + days))
done
## add the day of the month
dayofyear=$((dayofyear+day))
#echo $dayofyear
########## Add the day fo year (-1) to the epochtime
#(-1, since eg. Jan 1 is not 24 hours into Jan1 )
epochtime=$((epochtime + (dayofyear -1) * 24*60*60))
#echo $epochtime
################## hours, minutes, seconds
OFS=$IFS
IFS=":"
set -- $time
hours=$1
minutes=$2
seconds=$3
epochtime=$((epochtime + (hours * 60 * 60) + (minutes * 60) + seconds))
IFS=$OFS
################## Time zone
case $zone in
'GMT') zonenumber=0
break;;
'EST') zonenumber=-5
break;;
'EDT') zonenumber=-4
break;;
esac
epochtime=$((epochtime + zonenumber * 60 * 60 ))
echo $epochtime
}
result=`date2epoch $datestring`
echo $result
I probably made a mistake somewhere and there may be a better way. Let me know if you find a bug, or a better way.
Once you have the epoch time, you can do some useful calculations... although converting that back into a date without the gnu utils... requires doing the above in reverse...
You can set a timezone for the duration of the query, thusly:
TZ=America/New_York date
Note the whitespace between the TZ
setting and the date
command. In Bourne-like and rc
-like shell, that sets the TZ
variable only for the command line. In other shells (csh
, tcsh
, fish
), you can always use the env
command instead:
env TZ=America/New_York date
tl;dr
On Linux systems. timezones are defined in files in the /usr/share/zoneinfo
directory. This structure is often referred to as the "Olson database" to honor its founding contributor.
The rules for each timezone are defined as text file lines which are then compiled into a binary file. The lines so compiled, define the zone name; a range of data and time during which the zone applies; an offset from UTC for the standard time; and the notation for defining how transition to-and-from daylight saving time occurs, if applicable.
For example, the directory "America" contains the requisite information for New York in the file America/New_York
as used, above.
Beware that the specification of a non-existent zone (file name) is silently ignored and UTC times are reported. For example, this reports an incorrect time:
TZ="America/New York" date ### WRONG ###
The Single UNIX Specification, version-3, known as SUSv3 or POSIX-2001, notes that for portability, the character string that identifies the timezone description should begin with a colon character. Thus, we can also write:
TZ=":America/New_York" date
TZ=":America/Los_Angeles" date
As an alternative method to the specification of timezones using a pathname to a description file, SUSv3 describes the POSIX model. In this format, a string is defined as:
std offset [dst[offset][,start-date[/time],end-date[/time]]]
where std
is the standard component name and dst
is the daylight saving one. Each name consists of three or more characters. The offset
is positive for timezones west of the prime meridian and negative for those east of the meridian. The offset is added to the local time to obtain UTC (formerly known as GMT). The start
and end
time fields indicate when the standard/daylight transitions occur.
For example, in the Eastern United States, standard time is 5-hours earlier than UTC, and we can specify EST5EDT
in lieu of America/New_York
. These alternatives are not always recognized, however, especially for zones outside of the United States and are best avoided.
HP-UX (an SUSv3 compliant UNIX) uses textual rules in /usr/lib/tztab
and the POSIX names like EST5EDT, CST6CDT, MST7MDT, PST8PDT. The file includes all of the historical rules for each time zone, akin to the Olson database.
NOTE: You should be able to find all of the timezones by inspecting the following directory: /usr/share/zoneinfo
.
Best Answer
if the user is allowed to use
at
command, this is the perfect use for that:if you get a message like "user blah is not able to run
at
", ask the syadmin to add this user toat.allow
file or remove fromat.deny
file, depending on how it is used in your environment.Unless of course you wish this days long sleep happen in the middle of your script. Even then you can cut up your script into two, writing variables you want to keep, to a file and when the time comes and second part of your script executes, it can read those variables from the stored file.