I have a date represented as 1231533845
I understand that is supposed to be Fri Jan 9 15:44:05 EST 2009
And that on OSX it can be decoded with:
date -j -f %s 1231533845
What's the equivalent command on linux?
You will use the date function, but with the option -d
date -d #1231533845
Related
I need to the date three days from today. On CentOS, I can run the below command.
date -I -d "-3 days"
Which outputs
2022-07-02
I need the same inside my Docker container which is running on Alpine Linux 3.14.6v.
When I execute the same command I am getting the error:
date: invalid date '-3 days'
Anyone knows the workaround for this?
From StackExchange.com:
https://unix.stackexchange.com/questions/206540/date-d-command-fails-on-docker-alpine-linux-container
BusyBox/Alpine version of date doesn't support -d options, even if the
help is exatly the same in the Ubuntu version as well as in others
more fat distros.
To work with -d options you just need to add coreutils package
A way to do it could be to use a bit of arithmetic on a timestamp, then translate the timestamp back into a date:
date -d "#$(( $(date +%s) - 3 * 24 * 60 * 60 ))"
Given
docker run --rm alpine:3.14 sh -c 'date;
date -d "#$(( $(date +%s) - 3 * 24 * 60 * 60 ))"'
It would yield:
Tue Jul 5 11:51:31 UTC 2022
Sat Jul 2 11:51:31 UTC 2022
I am trying to convert dates from different timezones with UNIX date (I am on Ubuntu 20.04).
With current date, it works well:
$ date
dim. 12 déc. 2021 11:59:16 CET
$ TZ=Pacific/Tahiti date
dim. 12 déc. 2021 00:59:32 -10
But when I am working with a string, it fails:
$ export testdate="2021/10/28 17:47:26"
$ date -d "$test"
jeu. 28 oct. 2021 17:47:26 CEST
$ TZ=Pacific/Tahiti date -d "$test"
jeu. 28 oct. 2021 17:47:26 -10
as I am expecting:
jeu 28 oct. 2021 05:47:26 -10
I don't understand why I don't get the proper shift. And of course if I try with a date and time where the day should also change, it doesn't work either:
$ export test="2021/10/28 7:47:26"
$ date -d "$test"
jeu. 28 oct. 2021 07:47:26 CEST
$ TZ=Pacific/Tahiti date -d "$test" "+%F %T %Z"
2021-10-28 07:47:26 -10
while I am expecting:
mer 27 oct. 2021 19:47:26 -10
why I don't get the proper shift
test="2021/10/28 17:47:26"
Is a date in unknown timezone. No one knows what timezone it is in, what the daylight is. GNU date tries to "guess" what offset you meant, it generally traverses TZ database for current timezone and just picks the first offset that matches. Also, specifying timezone is not enough to know what daylight it is, you have to be specific.
Also, because of the daylight time you can "go back" in time, it's now known what the offset to UTC is even when you know the timezone.
Also, you don't have to export it - date does not care about test environment variable.
Converting date in a different timezone with date
If the input is in UTC, tell date that.
$ LC_ALL=C TZ=Pacific/Tahiti date -d "2021/10/28 17:47:26 UTC"
Thu Oct 28 07:47:26 -10 2021
If the input is with any other offset, tell date that.
$ LC_ALL=C TZ=Pacific/Tahiti date -d "2021/10/28 17:47:26 CEST"
Thu Oct 28 05:47:26 -10 2021
Te parsing of GNU date of input format is generally a mystery. The documentation lists 2004-02-29 16:21:42 format as an example input, so I recommend that format. If you want to be exact, I recommend strptime from dateutils (or a real programming language).
One simple way is to convert time first to epoch time :
test="2021/10/28 17:47:26"
TZ=Pacific/Tahiti date -d #$(date -d "$test" +%s)
date -d "$test" +%s converts local time to epoch time.
TZ=Pacific/Tahiti date -d #$(date -d "$test" +%s) prints Tahiti time from epoch time.
I'm not fully confident, but i get the impression you're looking the following syntax:
LC_TIME="es_ES.UTF8" TZ="America/New_York" date --date='TZ="Europe/Amsterdam" 2021/10/28 17:47:26' "+%A %F %T %B"
That takes a predefined datetime (interpreted as being local to Amsterdam), adjusts the datetime (based on the time difference) to New York-time at that same moment; Then it prints that result with Spanish names for the months/weekdays (provided that language' locale is present on your system).
I am trying to figure out what the last value of running date -r on my mac correspond to. For example,
➜ ~ date -r 1615828584730
Fri Jul 27 10:32:10 PDT 53173
What does the five digit 53173 in this string mean?
I am migrating all my script from UNIX server to Linux server, but both the server have different date format.
How I can make both format same ?
UNIX:
bash-3.2$ date
Tuesday, 25 October 2016 15:57:04 BST
LINUX:
[ess#gmessd04 ~]$ date
Tue 25 Oct 16:01:20 BST 2016
Unix server version : SunOS 5.10
Linux server version : Linux 3.10
Thanks,
Shadab Hussain
You could use the parameter of the date command to get the same result on linux you have on unix.
$date "+%A, %d %B %k:%M:%S %Z"
For more info about the date modifier see manpage of date command:
$man date
If you need like to change the output of date without typing the parameter all the time, you could set it as alias:
$alias date='date "+%A, %d %B %k:%M:%S %Z"'
In linux bash when I enter date -d "1986-01-01" it shows error
date: invalid date "1986-01-01"
when date -d "1986-01-02" it works
when date -d "1987-01-01" it also works
Why date -d "1986-01-01" shows error in Linux Bash shell.
I am using Fedora 16
Nepal changed its timezone at the beginning of 1986. The following table is copied from the tzdata package:
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Asia/Kathmandu 5:41:16 - LMT 1920
5:30 - IST 1986
5:45 - NPT # Nepal Time
That means that on Jan 1 1986 the time from 00:00:00 to 00:14:59 is not valid. The following two commands show, that the first day of 1986 started with 00:15:00:
$ TZ=Asia/Kathmandu date -d '1985-12-31 23:59:59' '+%s'
504901799
$ TZ=Asia/Kathmandu date -d '1986-01-01 00:15:00' '+%s'
504901800
So the error message of date is correct. The date is invalid in this timezone. I am not sure what you are doing with the result of this command. However, you can try to use UTC because all dates are valid and unambiguous in UTC:
$ TZ=UTC date -d '1986-01-01'
Wed Jan 1 00:00:00 UTC 1986
I think you are using alphabet "O" in upper case instead of number "0" in the command :)