so i am having this weird problem with my clock on pc. I am currently using Kali Linux 2018.1.
Basically my problem is that my computer time is one hour behind every time i start my pc. So is my hardware clock. What i find even weirder is that date -u and hwclock -u display different results:
root#horse:/etc# date
Sat Mar 3 22:50:56 CET 2018
root#horse:/etc# hwclock
2018-03-03 22:50:59.654599+0100
root#horse:/etc# date -u
Sat Mar 3 21:51:03 UTC 2018
root#horse:/etc# hwclock -u
2018-03-03 23:51:09.904595+0100
root#horse:/etc#
The time from hwclock -u is the correct one.
Can you please help me understand and solve this issue?
Since hwclock -u showed the correct time:
#hwclock -u > date -s
#hwclock -w
This seemed to do the trick.
Alternatively :
#date -s M/D/Y +hh:mm
#hwclock -w
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 need the process id of a process (here sleep 20) started remotely via SSH and sudo.
date is inserted to illustrate the duration of the SSH connection. Without connection there is also no process on my remote machine, of course.
$ date; ssh pc1 "sleep 20 & echo \$!"; date # works
Mi 20. Jan 16:18:29 CET 2016
11540
Mi 20. Jan 16:18:50 CET 2016
$ date; ssh pc1 "echo password | sudo -S sleep 20"; date # works
Mi 20. Jan 16:20:44 CET 2016
[sudo] password for lab: Mi 20. Jan 16:21:04 CET 2016
$ date; ssh pc1 "echo password | sudo -S sleep 20 & echo \$!"; date # does not
Mi 20. Jan 16:21:55 CET 2016
11916
Mi 20. Jan 16:21:56 CET 2016
On a second machine the last, complete command works fine:
$ date; ssh pc2 "echo password | sudo -S sleep 20 & echo \$!"; date
Mi 20. Jan 16:23:40 CET 2016
6035
[sudo] password for lab: Mi 20. Jan 16:24:01 CET 2016
Any suggestion why there is this different behaviour of the two machines?
Info: I know the risk of clear passwords but it's a shared account in an isolated test network.
Something like this?
$ remote_pid=$(ssh mauro#planck 'sleep 20 > /dev/null 2>&1 & echo $!')
$ echo $remote_pid
13878
or...
$ remote_pid=$(ssh mauro#planck 'echo secret | sudo -S sleep 20 > /tmp/log 2>&1 & echo $!')
It looks like an issue with incomplete process dependencies. With some additional milliseconds the connection (and process) keeps established the whole time.
$ date; ssh pc1 "echo password | sudo -S sleep 20 & echo \$! && sleep 0.01"; date
Do 21. Jan 14:50:39 CET 2016
[sudo] password for lab: 6841
Do 21. Jan 14:51:00 CET 2016
I'm getting two different timezones on Linux (CENTOS 5.6) depending on whether date is called locally or via ssh:
foo$ ssh me#bar date
Tue Nov 5 18:08:32 EST 2013
foo$ ssh me#bar
bar$ date
Tue Nov 5 17:09:16 CST 2013
/etc/localtime is set to central time:
$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 27 Nov 5 13:10 /etc/localtime -> /usr/share/zoneinfo/CST6CDT
TZ is set to America/Chicago in .bash_profile. If that line is commented out, time zone comes back as eastern rather than central.
I'm assuming this all means the computer believes in its heart that it's on eastern rather than central time and the TZ setting in the shell just overrides this, but I can't figure out WHY the computer thinks it's in eastern time.
edit
It turned out that a runaway process somewhere had actually overwritten the central time timezone file with an eastern time timezone file. Not easy to find, as the file contents are binary!
Did you check -> /etc/sysconfig/clock ?
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 :)