bug#30795: Issue with date command and EDT

[Jared Chagnon]

Forgot to include this:

OS Release:
Red Hat Enterprise Linux Server release 6.9 (Santiago)

Packages installed:
tzdata-2018c-1.el6.noarch
coreutils-8.4-46.0.1.el6.x86_64
coreutils-libs-8.4-46.0.1.el6.x86_64

Jared Chagnon
Systems Engineering Manager
P:  781.292.6033
M:  508.566.0081
jchag...@enservio.com
www.enservio.com

[cid:A7AEE8A5-9D9D-44B8-B77C-BE36F5D6A2C5@enservio.lan]

On Mar 13, 2018, at 9:10 AM, Jared Chagnon 
mailto:jchag...@enservio.com>> wrote:

Please see the issue below:

I setup a test script:

#/bin/bash

echo "`date`"
echo "`date +%z`"

currentdate=`date +%Y%m%d_%H%M%S`
echo "current date: $currentdate"

olddate=`date "+%Y%m%d_%H%M%S" --date='4 days ago'`
echo "old date 4 days ago: $olddate”

— Output —

./datetest.sh
Tue Mar 13 09:08:34 EDT 2018
-0400
current date: 20180313_090834
old date 4 days ago: 20180309_080834

— Notes ——

My local time zone is America\New_York.  Please note the date modification is 
not using EDT and resulting in EST.

Jared Chagnon
Systems Engineering Manager
P:  781.292.6033
M:  508.566.0081
jchag...@enservio.com
www.enservio.com

[cid:A7AEE8A5-9D9D-44B8-B77C-BE36F5D6A2C5@enservio.lan]

bug#22183: date returns incorrect string for Wednesday in Marathi

[Rafal Luzynski]

Indeed, it was a bug in glibc locale data [1] and has been fixed [2]
in version 2.17. If you mention Fedora the fix has been included
in Fedora 19. Please close this bug report, it was not a coreutils
issue and it has been fixed 5.5 years ago.

Regards,

Rafal

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=14694
[2] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=3b81309

bug#22183: date returns incorrect string for Wednesday in Marathi

[Paul Eggert]

On 03/13/2018 02:34 PM, Rafal Luzynski wrote:

Please close this bug report


Thanks for checking; closing.

bug#30814: Please increase the value of MAX_MON_WIDTH in ls.c

[Rafal Luzynski]

As we have introduced the support of nominative and genitive
month names in glibc [1] and we are going to provide the updated
locale data for Catalan language [2] it has been discovered [3]
that the current limit of the maximum length of the abbreviated
month name as displayed by "ls -l" will not work with the new
data for Catalan.  It is obligatory to precede the month name
with "de " (note: the space) so the abbreviated month names limited
to 5 characters will be ambiguous and therefore unreadable:

de ma  (should be "de mar" at least)
d’abr  (correct)
de ma  (should be "de mai" at least)
de ju  (should be "de jun" at least)
de ju  (should be "de jul" at least)

Increasing the value of MAX_MON_WIDTH to 6 characters will fix
the problem. The location of the constant is here: [4]

Although it has been also suggested in the same bug report that
there should be no additional limit for the month length.

This bug may be related with the coreutils bug #29377. [5]

Regards,

Rafal Luzynski


[1] https://sourceware.org/bugzilla/show_bug.cgi?id=10871
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=22848
[3] https://sourceware.org/bugzilla/show_bug.cgi?id=22848#c6
[4] http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/ls.c#n1099
[5] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29377

bug#30795: Issue with date command and EDT

[Assaf Gordon]

Hello,

On 2018-03-13 09:20 AM, Jared Chagnon wrote:

I setup a test script:

#/bin/bash

echo "`date`"
echo "`date +%z`"

currentdate=`date +%Y%m%d_%H%M%S`
echo "current date: $currentdate"

olddate=`date "+%Y%m%d_%H%M%S" --date='4 days ago'`
echo "old date 4 days ago: $olddate”


An unrelated suggestion:
There's no need to use backticks to execute date and return the value
and then echo it. Simply running 'date' will print the date to STDOUT.
e.g.

  date
  date +%z
  printf "current date: "
  date +%Y%m%d_%H%M%S

or even:

  date +"Current Date: %Y%m%d_%H%M%S"


— Output —

./datetest.sh
Tue Mar 13 09:08:34 EDT 2018
-0400
current date: 20180313_090834
old date 4 days ago: 20180309_080834

— Notes ——

My local time zone is America\New_York.  Please note the date modification is 
not using EDT and resulting in EST.


First,
lets verify our baseline assumptions about New York time zones
are the same:

EST = Eastern Standard Time, used in autumn/winter = UTC-05:00.
EDT = Eastern Daylight Time, used in spring/summer = UTC-04:00.

In 2018, daylight saving time (DST) started on March 11th, 2:am.
"started" here means switching from EST to EDT.

That is:
  2018-03-09 is EST (still winter, DST not used).
  2018-03-13 is EDT (summer time, DST used).

This can be verified with:

  $ TZ="America/New_York" date +%F-%Z -d '2018-03-09'
  2018-03-09-EST
  $ TZ="America/New_York" date +%F-%Z -d '2018-03-13'
  2018-03-13-EDT


Second,
in your example, the current date is 2018-03-13 (and implied: EDT),
and subtracting 4 days gives 2018-03-09.
Due to your time zone, 'date' knows that your timezone does use DST.
This date adjustment also crossed the DST change date (march 11th),
so date correctly adjusted the clock one hour backwards (from
09:08:34 to 08:08:34.


Third,
in newer version we've added a "--debug" option that helps
diagnosing such issues:

  $ TZ="America/New_York" \
 date --debug +%Y%m%d_%H%M%S_%Z --date="4 days ago"
  date: parsed relative part: -4 day(s)
  date: input timezone: TZ="America/New_York" environment value
  date: using current time as starting value: '21:13:23'
  date: using current date as starting value: '(Y-M-D) 2018-03-13'
  date: starting date/time: '(Y-M-D) 2018-03-13 21:13:23'
  date: warning: when adding relative days, it is recommended to \
specify noon
  date: after date adjustment (+0 years, +0 months, -4 days),
  date: new date/time = '(Y-M-D) 2018-03-09 20:13:23'
->date: warning: daylight saving time changed after date adjustment <-
  date: '(Y-M-D) 2018-03-09 20:13:23' = 1520644403 epoch-seconds
  date: timezone: TZ="America/New_York" environment value
  date: final: 1520644403.136862048 (epoch-seconds)
  date: final: (Y-M-D) 2018-03-10 01:13:23 (UTC)
  date: final: (Y-M-D) 2018-03-09 20:13:23 (UTC-05)
  20180309_201323_EST



Fourth,
There is a subtle issue of how 'date' knows when to do DST adjustments
(and when not to).

When using 'date' without specifying the current date/time, it
gets the date,time and time zone from your operating system.

In your case it was "America/New_York". 'date' then checked the timezone
database and so it knows that NY does use daylight saving time,
and it knows that currently it is EDT, will subtract an hour when 
switching to EST.


When giving 'date' an explicit date without time zone, it doesn't
know if DST should be used or not - and assumes it should not be used.
Therefore it will not subtract an hour.

Observe the following:

  $ date +%F
  2018-03-13

  # Without timezone - hour stays the same:
  $ date -d '2018-03-13 09:00:00 4 days ago'
  Fri Mar  9 09:00:00 EST 2018

  # With timezone that indicates DST - hour is adjusted:
  $ date -d '2018-03-13 09:00:00 EDT 4 days ago'
  Fri Mar  9 08:00:00 EST 2018

These issues can be troubleshooted using the "--debug" option.



Fifth,
There is also one additional nuance:
If you don't specify the hour, 'date' assumes midnight.
If DST is active, it will subtract an hour resulting in 11pm
in the previous day:

  $ date -d '2018-03-13 4 days ago'
  Fri Mar  9 00:00:00 EST 2018

  $ date -d '2018-03-13 EDT 4 days ago'
  Thu Mar  8 23:00:00 EST 2018

This will be very confusing if one prints only the date, eg:

  $ date -d '2018-03-13 4 days ago' +%F
  2018-03-09

  $ date -d '2018-03-13 EDT 4 days ago' +%F
  2018-03-08

Therefore it is always recommended to use noon (12pm)
as explicit time when adjusting days (and when using --debug
there will be a warning to that effect).








If this explanation solves the issue - great.
If not, please provide further details and examples of the commands and
output you expect.

regards,
 - assaf