Your message dated Sun, 8 May 2011 20:09:14 -0600
with message-id <[email protected]>
and subject line Re: Bug#625909: coreutils: date --date="2010-10-17" +'%c' fails
has caused the Debian Bug report #625909,
regarding coreutils: date --date="2010-10-17" +'%c' fails
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
625909: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625909
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: coreutils
Version: 8.5-1
Severity: important
Tags: l10n
david@rascar:~ 19 $ date --date="2010-10-17" +'%c'
date: invalid date 2010-10-17'
david@rascar:~ 20 $ ltrace date --date="2010-10-17" +'%c'
__libc_start_main(0x8049840, 3, 0xbffeee24, 0x8051c90, 0x8051c80
<unfinished ...>
strrchr("date", '/')
= NULL
setlocale(6, "")
= "en_US.UTF-8"
bindtextdomain("coreutils", "/usr/share/locale")
= "/usr/share/locale"
textdomain("coreutils")
= "coreutils"
__cxa_atexit(0x804d030, 0, 0, 0, 0xbffeed78)
= 0
getenv("POSIXLY_CORRECT")
= NULL
strncmp("date", "date=2010-10-17", 4)
= 0
strlen("date")
= 4
strlen("date=2010-10-17")
= 15
clock_gettime(0, 0xbffeec74, 0xb770e0c4, 0xb7706318,
0x1c93bb9d) = 0
localtime(0xbffeec74)
= 0xb78606a0
localtime(0xbffeec7c)
= 0xb78606a0
localtime(0xbffeec7c)
= 0xb78606a0
strcmp("BRT", "BRST")
= 1
mktime(0xbffeec48, 0x9758890, 0x8048894, 0xb7714054, 0x80485a4)
= 0x4cba66b0
free(NULL)
= <void>
__errno_location()
= 0xb76ec688
__ctype_get_mb_cur_max(0xb7706300, 0x80488a2, 4, 10, 17)
= 6
dcgettext(0, 0x80547c4, 5, 10, 17)
= 0x80547c4
dcgettext(0, 0x80543a4, 5, 10, 17)
= 0x80543a4
strlen("'")
= 1
dcgettext(0, 0x8051e57, 5, 0x8052fa0, 0)
= 0x8051e57
error(1, 0, 0x8051e57, 0x8055e80, 0date: invalid date 2010-10-17'
<unfinished ...>
__fpending(0xb785d4e0, 0xbffeec70, 0xb78aaac0,
0xbffeec44, 0xb78973e2) = 0
fclose(0xb785d4e0)
= 0
__fpending(0xb785d580, 0xbffeec70, 0xb78aaac0, 0xbffeec44,
0xb78973e2) = 0
fclose(0xb785d580)
= 0
+++ exited (status 1) +++
david@rascar:~ 21 $
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (800, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.38-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages coreutils depends on:
ii libacl1 2.2.49-4 Access control list shared library
ii libattr1 1:2.4.44-2 Extended attribute shared library
ii libc6 2.13-2 Embedded GNU C Library: Shared lib
ii libselinux1 2.0.98-1+b1 SELinux runtime shared libraries
coreutils recommends no packages.
coreutils suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
David Pirotte wrote:
> -] your suggestion of passing a time away from midnight
> did work, many thanks.
Good!
> IMHO though, when using date passing a date 'per se' and no time, it should
> default
> the time to an existing time value in the TZ, DST taken into account and
> independently of the date itself - possible? - which might be erroneous [I
> use 'date' to check the validity of 'user dates' for example], don't you
> think so?
If I were the one who had created the parser, and having the
experience and hindsight that I have after all of these years, then I
would default it to noon. But I did not write it. If I recall
correctly it was originally a date parser from the old news software
that has been adapted and adapted and adapted again and eventually
made its way into the date program's human date parser. The behavior
you are talking about is behavior that has been there for more than a
decade. It is fully documented as behaving as it does. Changing old
behavior such as that almost always creates a lot of bugs because it
breaks anything that has come to rely upon the behavior, whatever it
happens to be.
> > $ TZ=US/Mountain date --date="2010-10-17" +'%c'
> > Sun 17 Oct 2010 12:00:00 AM MDT
>
> You will if you temporarily set yourself in the BRST TZ [see the ltrace
> output I
> sent]
That isn't sufficient for me. I cannot recreate the problem.
$ TZ=BRST date --date="2010-10-17" +'%c'
Sun 17 Oct 2010 12:00:00 AM BRST
Works for me. But I think that is because BRST is not the correct
string to use to set the timezone. Dusting off the globe I tried
Brazil/East though and that was able to trigger the case.
$ TZ=Brazil/East date --date="2010-10-17"
date: invalid date `2010-10-17'
$ TZ=Brazil/East date --date="2010-10-17 12:00"
Sun Oct 17 12:00:00 BRST 2010
> > Try using a time away from midnight and toward noon which is usually
> > far away from DST changes.
> >
> > $ TZ=US/Mountain date --date="2010-10-17 12:00" +'%c'
> > Sun 17 Oct 2010 12:00:00 PM MDT
>
> This work here too, many thanks:
>
> david@rascar:~ 1 $ date --date="2010-10-17 12:00" +'%c'
> Sun 17 Oct 2010 12:00:00 PM BRST
That is the right solution. Therefore I am going to close the bug report.
Thanks,
Bob
--- End Message ---
