Get date of Monday two weeks ago from particular date using GNU date
I understand the command date -d 'last-monday - 14 days' +%Y%m%d
will print the Monday two weeks ago from "Today's date". I need a way to test this for different dates and see the result. Almost like I need to mention the date command to do calculations off a relative date.
I need something to test with different dateslike :
date -d 'last-monday - 14 days' %Y%m%d from 20190315
date -d 'last-monday - 14 days' %Y%m%d from 20180217
date -d 'last-monday - 14 days' %Y%m%d from 201700914
and see the respective outputs.
linux date
New contributor
add a comment |
I understand the command date -d 'last-monday - 14 days' +%Y%m%d
will print the Monday two weeks ago from "Today's date". I need a way to test this for different dates and see the result. Almost like I need to mention the date command to do calculations off a relative date.
I need something to test with different dateslike :
date -d 'last-monday - 14 days' %Y%m%d from 20190315
date -d 'last-monday - 14 days' %Y%m%d from 20180217
date -d 'last-monday - 14 days' %Y%m%d from 201700914
and see the respective outputs.
linux date
New contributor
You'd want a way to get (respectively to your example) results such as:20190225
and20180129
and20170828
, am I correct ?
– LL3
3 hours ago
add a comment |
I understand the command date -d 'last-monday - 14 days' +%Y%m%d
will print the Monday two weeks ago from "Today's date". I need a way to test this for different dates and see the result. Almost like I need to mention the date command to do calculations off a relative date.
I need something to test with different dateslike :
date -d 'last-monday - 14 days' %Y%m%d from 20190315
date -d 'last-monday - 14 days' %Y%m%d from 20180217
date -d 'last-monday - 14 days' %Y%m%d from 201700914
and see the respective outputs.
linux date
New contributor
I understand the command date -d 'last-monday - 14 days' +%Y%m%d
will print the Monday two weeks ago from "Today's date". I need a way to test this for different dates and see the result. Almost like I need to mention the date command to do calculations off a relative date.
I need something to test with different dateslike :
date -d 'last-monday - 14 days' %Y%m%d from 20190315
date -d 'last-monday - 14 days' %Y%m%d from 20180217
date -d 'last-monday - 14 days' %Y%m%d from 201700914
and see the respective outputs.
linux date
linux date
New contributor
New contributor
edited 3 hours ago
Kusalananda
136k17257426
136k17257426
New contributor
asked 4 hours ago
Eternal LearnerEternal Learner
101
101
New contributor
New contributor
You'd want a way to get (respectively to your example) results such as:20190225
and20180129
and20170828
, am I correct ?
– LL3
3 hours ago
add a comment |
You'd want a way to get (respectively to your example) results such as:20190225
and20180129
and20170828
, am I correct ?
– LL3
3 hours ago
You'd want a way to get (respectively to your example) results such as:
20190225
and 20180129
and 20170828
, am I correct ?– LL3
3 hours ago
You'd want a way to get (respectively to your example) results such as:
20190225
and 20180129
and 20170828
, am I correct ?– LL3
3 hours ago
add a comment |
5 Answers
5
active
oldest
votes
$ date
Wed Mar 20 15:02:23 MST 2019
$ date -d "last-monday"
Mon Mar 18 00:00:00 MST 2019
$ date -d "last-monday - 1 week"
Mon Mar 11 00:00:00 MST 2019
2
The issue seems to be finding the date of the Monday two weeks before a particular date.
– Kusalananda
4 hours ago
add a comment |
On at least Debian there is a faketime
package
faketime '2019-03-15' date
Fri 15 Mar 00:00:00 GMT 2019
faketime '2019-03-15' date --date 'last monday - 14 days'
Mon 25 Feb 00:00:00 GMT 2019
add a comment |
#!/bin/bash
# Our given dates
dates=(
20190315
20180217
20170914
)
# Loop over the given dates
for thedate in "${dates[@]}"; do
# Get day of the week as digit (1 is Monday, 7 is Sunday)
day=$( date -d "$thedate" +%u )
# The Monday the same week is $(( day - 1 )) days earlier than the given date.
# The Monday two weeks earlier is 14 days earlier still.
date -d "$thedate -$(( day - 1 + 14 )) days" +"$thedate --> %Y%m%d"
done
Output:
20190315 --> 20190225
20180217 --> 20180129
20170914 --> 20170828
The difficult bit about this is to figure out how to construct the correct --date
or -d
string for GNU date
to compute the final date. I opted for computing the day of week of the given date, and then using that to compute a date string that offsets the given date by a number of days.
The actual strings that ends up being used for the option argument to -d
in the above script, using the dates given in the script, are
20190315 -18 days
20180217 -19 days
20170914 -17 days
Condensing the script into a single command that does the computation for a single date in $thedate
:
date -d "$thedate -$(date -d "$thedate" +%u) days -13 days" +%Y%m%d
or
date -d "$thedate -$(date -d "$thedate" +"-%u days -13 days")" +%Y%m%d
add a comment |
Use the date
command's -s
/--set
option:
# date
Wed Mar 20 23:02:18 CET 2019
# date -s '20190315' > /dev/null; date -d 'last-monday - 14 days'
Mon Feb 25 00:00:00 CET 2019
Depending on your system, you might have to prefix with sudo
or reset afterwards via ntpdate
New contributor
Setting the system's clock seems like overkill just to get the correct output. It may also confuse certain services and scheduled tasks, and other users of the system if it's a multi-user system.
– Kusalananda
4 hours ago
@Kusalananda I agree, in principle, but most modern systems will automatically resync via ntp anyway. When I tested this, date returned the correct time immediately afterwards; hence the;
instead of using two separate commands to show what I'm doing. But if you really don't want to touch your system time, there does exist afaketime
package.
– Entropy0
3 hours ago
Thentpd
daemon won't resync if you exceed its the 300 second variance.
– roaima
3 hours ago
Then there is something else going on in my system (Mint 19), because 5d > 300s and as I said: running above command didn't affect anything beyond the commands in the current line. In fact:# date -s '19700102' ; date ; sleep 1 ; date
yieldsFri Jan 2 00:00:00 CET 1970
Fri Jan 2 00:00:00 CET 1970
Wed Mar 20 23:49:26 CET 2019
– Entropy0
3 hours ago
Maybe you're runningntpdate
fromcron
(ugh), or perhapschrony
has a larger leeway. Or there again there's whatever thesystemd
borg has done to NTP.
– roaima
3 hours ago
|
show 1 more comment
The overkill solution:
Create a bare-bones virtual machine.
Run it in single user mode,
so no background services are running.
Just to be sure, double-check that NTP is not running.
Then set the date to whatever you want to set it to,
and do your tests.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Eternal Learner is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f507549%2fget-date-of-monday-two-weeks-ago-from-particular-date-using-gnu-date%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
$ date
Wed Mar 20 15:02:23 MST 2019
$ date -d "last-monday"
Mon Mar 18 00:00:00 MST 2019
$ date -d "last-monday - 1 week"
Mon Mar 11 00:00:00 MST 2019
2
The issue seems to be finding the date of the Monday two weeks before a particular date.
– Kusalananda
4 hours ago
add a comment |
$ date
Wed Mar 20 15:02:23 MST 2019
$ date -d "last-monday"
Mon Mar 18 00:00:00 MST 2019
$ date -d "last-monday - 1 week"
Mon Mar 11 00:00:00 MST 2019
2
The issue seems to be finding the date of the Monday two weeks before a particular date.
– Kusalananda
4 hours ago
add a comment |
$ date
Wed Mar 20 15:02:23 MST 2019
$ date -d "last-monday"
Mon Mar 18 00:00:00 MST 2019
$ date -d "last-monday - 1 week"
Mon Mar 11 00:00:00 MST 2019
$ date
Wed Mar 20 15:02:23 MST 2019
$ date -d "last-monday"
Mon Mar 18 00:00:00 MST 2019
$ date -d "last-monday - 1 week"
Mon Mar 11 00:00:00 MST 2019
answered 4 hours ago
DopeGhotiDopeGhoti
46.4k56190
46.4k56190
2
The issue seems to be finding the date of the Monday two weeks before a particular date.
– Kusalananda
4 hours ago
add a comment |
2
The issue seems to be finding the date of the Monday two weeks before a particular date.
– Kusalananda
4 hours ago
2
2
The issue seems to be finding the date of the Monday two weeks before a particular date.
– Kusalananda
4 hours ago
The issue seems to be finding the date of the Monday two weeks before a particular date.
– Kusalananda
4 hours ago
add a comment |
On at least Debian there is a faketime
package
faketime '2019-03-15' date
Fri 15 Mar 00:00:00 GMT 2019
faketime '2019-03-15' date --date 'last monday - 14 days'
Mon 25 Feb 00:00:00 GMT 2019
add a comment |
On at least Debian there is a faketime
package
faketime '2019-03-15' date
Fri 15 Mar 00:00:00 GMT 2019
faketime '2019-03-15' date --date 'last monday - 14 days'
Mon 25 Feb 00:00:00 GMT 2019
add a comment |
On at least Debian there is a faketime
package
faketime '2019-03-15' date
Fri 15 Mar 00:00:00 GMT 2019
faketime '2019-03-15' date --date 'last monday - 14 days'
Mon 25 Feb 00:00:00 GMT 2019
On at least Debian there is a faketime
package
faketime '2019-03-15' date
Fri 15 Mar 00:00:00 GMT 2019
faketime '2019-03-15' date --date 'last monday - 14 days'
Mon 25 Feb 00:00:00 GMT 2019
answered 3 hours ago
roaimaroaima
45.7k758124
45.7k758124
add a comment |
add a comment |
#!/bin/bash
# Our given dates
dates=(
20190315
20180217
20170914
)
# Loop over the given dates
for thedate in "${dates[@]}"; do
# Get day of the week as digit (1 is Monday, 7 is Sunday)
day=$( date -d "$thedate" +%u )
# The Monday the same week is $(( day - 1 )) days earlier than the given date.
# The Monday two weeks earlier is 14 days earlier still.
date -d "$thedate -$(( day - 1 + 14 )) days" +"$thedate --> %Y%m%d"
done
Output:
20190315 --> 20190225
20180217 --> 20180129
20170914 --> 20170828
The difficult bit about this is to figure out how to construct the correct --date
or -d
string for GNU date
to compute the final date. I opted for computing the day of week of the given date, and then using that to compute a date string that offsets the given date by a number of days.
The actual strings that ends up being used for the option argument to -d
in the above script, using the dates given in the script, are
20190315 -18 days
20180217 -19 days
20170914 -17 days
Condensing the script into a single command that does the computation for a single date in $thedate
:
date -d "$thedate -$(date -d "$thedate" +%u) days -13 days" +%Y%m%d
or
date -d "$thedate -$(date -d "$thedate" +"-%u days -13 days")" +%Y%m%d
add a comment |
#!/bin/bash
# Our given dates
dates=(
20190315
20180217
20170914
)
# Loop over the given dates
for thedate in "${dates[@]}"; do
# Get day of the week as digit (1 is Monday, 7 is Sunday)
day=$( date -d "$thedate" +%u )
# The Monday the same week is $(( day - 1 )) days earlier than the given date.
# The Monday two weeks earlier is 14 days earlier still.
date -d "$thedate -$(( day - 1 + 14 )) days" +"$thedate --> %Y%m%d"
done
Output:
20190315 --> 20190225
20180217 --> 20180129
20170914 --> 20170828
The difficult bit about this is to figure out how to construct the correct --date
or -d
string for GNU date
to compute the final date. I opted for computing the day of week of the given date, and then using that to compute a date string that offsets the given date by a number of days.
The actual strings that ends up being used for the option argument to -d
in the above script, using the dates given in the script, are
20190315 -18 days
20180217 -19 days
20170914 -17 days
Condensing the script into a single command that does the computation for a single date in $thedate
:
date -d "$thedate -$(date -d "$thedate" +%u) days -13 days" +%Y%m%d
or
date -d "$thedate -$(date -d "$thedate" +"-%u days -13 days")" +%Y%m%d
add a comment |
#!/bin/bash
# Our given dates
dates=(
20190315
20180217
20170914
)
# Loop over the given dates
for thedate in "${dates[@]}"; do
# Get day of the week as digit (1 is Monday, 7 is Sunday)
day=$( date -d "$thedate" +%u )
# The Monday the same week is $(( day - 1 )) days earlier than the given date.
# The Monday two weeks earlier is 14 days earlier still.
date -d "$thedate -$(( day - 1 + 14 )) days" +"$thedate --> %Y%m%d"
done
Output:
20190315 --> 20190225
20180217 --> 20180129
20170914 --> 20170828
The difficult bit about this is to figure out how to construct the correct --date
or -d
string for GNU date
to compute the final date. I opted for computing the day of week of the given date, and then using that to compute a date string that offsets the given date by a number of days.
The actual strings that ends up being used for the option argument to -d
in the above script, using the dates given in the script, are
20190315 -18 days
20180217 -19 days
20170914 -17 days
Condensing the script into a single command that does the computation for a single date in $thedate
:
date -d "$thedate -$(date -d "$thedate" +%u) days -13 days" +%Y%m%d
or
date -d "$thedate -$(date -d "$thedate" +"-%u days -13 days")" +%Y%m%d
#!/bin/bash
# Our given dates
dates=(
20190315
20180217
20170914
)
# Loop over the given dates
for thedate in "${dates[@]}"; do
# Get day of the week as digit (1 is Monday, 7 is Sunday)
day=$( date -d "$thedate" +%u )
# The Monday the same week is $(( day - 1 )) days earlier than the given date.
# The Monday two weeks earlier is 14 days earlier still.
date -d "$thedate -$(( day - 1 + 14 )) days" +"$thedate --> %Y%m%d"
done
Output:
20190315 --> 20190225
20180217 --> 20180129
20170914 --> 20170828
The difficult bit about this is to figure out how to construct the correct --date
or -d
string for GNU date
to compute the final date. I opted for computing the day of week of the given date, and then using that to compute a date string that offsets the given date by a number of days.
The actual strings that ends up being used for the option argument to -d
in the above script, using the dates given in the script, are
20190315 -18 days
20180217 -19 days
20170914 -17 days
Condensing the script into a single command that does the computation for a single date in $thedate
:
date -d "$thedate -$(date -d "$thedate" +%u) days -13 days" +%Y%m%d
or
date -d "$thedate -$(date -d "$thedate" +"-%u days -13 days")" +%Y%m%d
edited 3 hours ago
answered 3 hours ago
KusalanandaKusalananda
136k17257426
136k17257426
add a comment |
add a comment |
Use the date
command's -s
/--set
option:
# date
Wed Mar 20 23:02:18 CET 2019
# date -s '20190315' > /dev/null; date -d 'last-monday - 14 days'
Mon Feb 25 00:00:00 CET 2019
Depending on your system, you might have to prefix with sudo
or reset afterwards via ntpdate
New contributor
Setting the system's clock seems like overkill just to get the correct output. It may also confuse certain services and scheduled tasks, and other users of the system if it's a multi-user system.
– Kusalananda
4 hours ago
@Kusalananda I agree, in principle, but most modern systems will automatically resync via ntp anyway. When I tested this, date returned the correct time immediately afterwards; hence the;
instead of using two separate commands to show what I'm doing. But if you really don't want to touch your system time, there does exist afaketime
package.
– Entropy0
3 hours ago
Thentpd
daemon won't resync if you exceed its the 300 second variance.
– roaima
3 hours ago
Then there is something else going on in my system (Mint 19), because 5d > 300s and as I said: running above command didn't affect anything beyond the commands in the current line. In fact:# date -s '19700102' ; date ; sleep 1 ; date
yieldsFri Jan 2 00:00:00 CET 1970
Fri Jan 2 00:00:00 CET 1970
Wed Mar 20 23:49:26 CET 2019
– Entropy0
3 hours ago
Maybe you're runningntpdate
fromcron
(ugh), or perhapschrony
has a larger leeway. Or there again there's whatever thesystemd
borg has done to NTP.
– roaima
3 hours ago
|
show 1 more comment
Use the date
command's -s
/--set
option:
# date
Wed Mar 20 23:02:18 CET 2019
# date -s '20190315' > /dev/null; date -d 'last-monday - 14 days'
Mon Feb 25 00:00:00 CET 2019
Depending on your system, you might have to prefix with sudo
or reset afterwards via ntpdate
New contributor
Setting the system's clock seems like overkill just to get the correct output. It may also confuse certain services and scheduled tasks, and other users of the system if it's a multi-user system.
– Kusalananda
4 hours ago
@Kusalananda I agree, in principle, but most modern systems will automatically resync via ntp anyway. When I tested this, date returned the correct time immediately afterwards; hence the;
instead of using two separate commands to show what I'm doing. But if you really don't want to touch your system time, there does exist afaketime
package.
– Entropy0
3 hours ago
Thentpd
daemon won't resync if you exceed its the 300 second variance.
– roaima
3 hours ago
Then there is something else going on in my system (Mint 19), because 5d > 300s and as I said: running above command didn't affect anything beyond the commands in the current line. In fact:# date -s '19700102' ; date ; sleep 1 ; date
yieldsFri Jan 2 00:00:00 CET 1970
Fri Jan 2 00:00:00 CET 1970
Wed Mar 20 23:49:26 CET 2019
– Entropy0
3 hours ago
Maybe you're runningntpdate
fromcron
(ugh), or perhapschrony
has a larger leeway. Or there again there's whatever thesystemd
borg has done to NTP.
– roaima
3 hours ago
|
show 1 more comment
Use the date
command's -s
/--set
option:
# date
Wed Mar 20 23:02:18 CET 2019
# date -s '20190315' > /dev/null; date -d 'last-monday - 14 days'
Mon Feb 25 00:00:00 CET 2019
Depending on your system, you might have to prefix with sudo
or reset afterwards via ntpdate
New contributor
Use the date
command's -s
/--set
option:
# date
Wed Mar 20 23:02:18 CET 2019
# date -s '20190315' > /dev/null; date -d 'last-monday - 14 days'
Mon Feb 25 00:00:00 CET 2019
Depending on your system, you might have to prefix with sudo
or reset afterwards via ntpdate
New contributor
New contributor
answered 4 hours ago
Entropy0Entropy0
362
362
New contributor
New contributor
Setting the system's clock seems like overkill just to get the correct output. It may also confuse certain services and scheduled tasks, and other users of the system if it's a multi-user system.
– Kusalananda
4 hours ago
@Kusalananda I agree, in principle, but most modern systems will automatically resync via ntp anyway. When I tested this, date returned the correct time immediately afterwards; hence the;
instead of using two separate commands to show what I'm doing. But if you really don't want to touch your system time, there does exist afaketime
package.
– Entropy0
3 hours ago
Thentpd
daemon won't resync if you exceed its the 300 second variance.
– roaima
3 hours ago
Then there is something else going on in my system (Mint 19), because 5d > 300s and as I said: running above command didn't affect anything beyond the commands in the current line. In fact:# date -s '19700102' ; date ; sleep 1 ; date
yieldsFri Jan 2 00:00:00 CET 1970
Fri Jan 2 00:00:00 CET 1970
Wed Mar 20 23:49:26 CET 2019
– Entropy0
3 hours ago
Maybe you're runningntpdate
fromcron
(ugh), or perhapschrony
has a larger leeway. Or there again there's whatever thesystemd
borg has done to NTP.
– roaima
3 hours ago
|
show 1 more comment
Setting the system's clock seems like overkill just to get the correct output. It may also confuse certain services and scheduled tasks, and other users of the system if it's a multi-user system.
– Kusalananda
4 hours ago
@Kusalananda I agree, in principle, but most modern systems will automatically resync via ntp anyway. When I tested this, date returned the correct time immediately afterwards; hence the;
instead of using two separate commands to show what I'm doing. But if you really don't want to touch your system time, there does exist afaketime
package.
– Entropy0
3 hours ago
Thentpd
daemon won't resync if you exceed its the 300 second variance.
– roaima
3 hours ago
Then there is something else going on in my system (Mint 19), because 5d > 300s and as I said: running above command didn't affect anything beyond the commands in the current line. In fact:# date -s '19700102' ; date ; sleep 1 ; date
yieldsFri Jan 2 00:00:00 CET 1970
Fri Jan 2 00:00:00 CET 1970
Wed Mar 20 23:49:26 CET 2019
– Entropy0
3 hours ago
Maybe you're runningntpdate
fromcron
(ugh), or perhapschrony
has a larger leeway. Or there again there's whatever thesystemd
borg has done to NTP.
– roaima
3 hours ago
Setting the system's clock seems like overkill just to get the correct output. It may also confuse certain services and scheduled tasks, and other users of the system if it's a multi-user system.
– Kusalananda
4 hours ago
Setting the system's clock seems like overkill just to get the correct output. It may also confuse certain services and scheduled tasks, and other users of the system if it's a multi-user system.
– Kusalananda
4 hours ago
@Kusalananda I agree, in principle, but most modern systems will automatically resync via ntp anyway. When I tested this, date returned the correct time immediately afterwards; hence the
;
instead of using two separate commands to show what I'm doing. But if you really don't want to touch your system time, there does exist a faketime
package.– Entropy0
3 hours ago
@Kusalananda I agree, in principle, but most modern systems will automatically resync via ntp anyway. When I tested this, date returned the correct time immediately afterwards; hence the
;
instead of using two separate commands to show what I'm doing. But if you really don't want to touch your system time, there does exist a faketime
package.– Entropy0
3 hours ago
The
ntpd
daemon won't resync if you exceed its the 300 second variance.– roaima
3 hours ago
The
ntpd
daemon won't resync if you exceed its the 300 second variance.– roaima
3 hours ago
Then there is something else going on in my system (Mint 19), because 5d > 300s and as I said: running above command didn't affect anything beyond the commands in the current line. In fact:
# date -s '19700102' ; date ; sleep 1 ; date
yields Fri Jan 2 00:00:00 CET 1970
Fri Jan 2 00:00:00 CET 1970
Wed Mar 20 23:49:26 CET 2019
– Entropy0
3 hours ago
Then there is something else going on in my system (Mint 19), because 5d > 300s and as I said: running above command didn't affect anything beyond the commands in the current line. In fact:
# date -s '19700102' ; date ; sleep 1 ; date
yields Fri Jan 2 00:00:00 CET 1970
Fri Jan 2 00:00:00 CET 1970
Wed Mar 20 23:49:26 CET 2019
– Entropy0
3 hours ago
Maybe you're running
ntpdate
from cron
(ugh), or perhaps chrony
has a larger leeway. Or there again there's whatever the systemd
borg has done to NTP.– roaima
3 hours ago
Maybe you're running
ntpdate
from cron
(ugh), or perhaps chrony
has a larger leeway. Or there again there's whatever the systemd
borg has done to NTP.– roaima
3 hours ago
|
show 1 more comment
The overkill solution:
Create a bare-bones virtual machine.
Run it in single user mode,
so no background services are running.
Just to be sure, double-check that NTP is not running.
Then set the date to whatever you want to set it to,
and do your tests.
add a comment |
The overkill solution:
Create a bare-bones virtual machine.
Run it in single user mode,
so no background services are running.
Just to be sure, double-check that NTP is not running.
Then set the date to whatever you want to set it to,
and do your tests.
add a comment |
The overkill solution:
Create a bare-bones virtual machine.
Run it in single user mode,
so no background services are running.
Just to be sure, double-check that NTP is not running.
Then set the date to whatever you want to set it to,
and do your tests.
The overkill solution:
Create a bare-bones virtual machine.
Run it in single user mode,
so no background services are running.
Just to be sure, double-check that NTP is not running.
Then set the date to whatever you want to set it to,
and do your tests.
answered 3 hours ago
G-ManG-Man
13.5k93768
13.5k93768
add a comment |
add a comment |
Eternal Learner is a new contributor. Be nice, and check out our Code of Conduct.
Eternal Learner is a new contributor. Be nice, and check out our Code of Conduct.
Eternal Learner is a new contributor. Be nice, and check out our Code of Conduct.
Eternal Learner is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f507549%2fget-date-of-monday-two-weeks-ago-from-particular-date-using-gnu-date%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You'd want a way to get (respectively to your example) results such as:
20190225
and20180129
and20170828
, am I correct ?– LL3
3 hours ago