Re: get_date returning false

2005-04-15 Thread Mark D. Baushke 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Derek,

Your script arrived here with linewrap problems... after I
fixed them, I get the following results with various boxes
I can access today...

I ran the attached script with three different arguments and
here are the results:

Timezone TestedResult  Host (OS Release Hardware)
Asia/Calcutta  false   AIX 4.3 unknown
Europe/London  false   AIX 4.3 unknown
Pacific/Honolulu   false   AIX 4.3 unknown

Asia/Calcutta  trueFedora Core release 3 GNU/Linux i686
Europe/London  trueFedora Core releaes 3 GNU/Linux i686

Asia/Calcutta  trueFreeBSD 4.10-RELEASE-p2 i386
Europe/London  trueFreeBSD 4.10-RELEASE-p2 i386
Pacific/Honolulu   trueFreeBSD 4.10-RELEASE-p2 i386

Asia/Calcutta  trueFreeBSD 4.2-RELEASE i386
Europe/London  trueFreeBSD 4.2-RELEASE i386
Pacific/Honolulu   trueFreeBSD 4.2-RELEASE i386

Asia/Calcutta  trueFreeBSD 5.2-RELEASE i386
Europe/London  trueFreeBSD 5.2-RELEASE i386
Pacific/Honolulu   trueFreeBSD 5.2-RELEASE i386

Asia/Calcutta  trueGentoo 1.4.16 GNU/Linux i686
Europe/London  trueGentoo 1.4.16 GNU/Linux i686
Pacific/Honolulu   trueGentoo 1.4.16 GNU/Linux i686

Asia/Calcutta  false   SunOS 5.8 SUNW,Sun-Blade-1000
Europe/London  false   SunOS 5.8 SUNW,Sun-Blade-1000
Pacific/Honolulu   false   SunOS 5.8 SUNW,Sun-Blade-1000

Asia/Calcutta  false   NetBSD 2.99.15 i386
Europe/London  false   NetBSD 2.99.15 i386
Pacific/Honolulu   false   NetBSD 2.99.15 i386

Asia/Calcutta  false   SunOS 5.7 SUNW,UltraSparc-IIi-cEngine
Europe/London  false   SunOS 5.7 SUNW,UltraSparc-IIi-cEngine
Pacific/Honolulu   false   SunOS 5.7 SUNW,UltraSparc-IIi-cEngine

Asia/Calcutta  trueSunOS 5.9 SUNW,Ultra-80
Europe/London  trueSunOS 5.9 SUNW,Ultra-80
Pacific/Honolulu   trueSunOS 5.9 SUNW,Ultra-80

Asia/Calcutta  false   UNICOS 9.0 CRAY Y-MP
Europe/London  false   UNICOS 9.0 CRAY Y-MP
Pacific/Honolulu   false   UNICOS 9.0 CRAY Y-MP

Enjoy!
-- Mark

 --- tz-test.sh ---
:
# Prep for future calls to valid_timezone().
#
# This should set $UTZ to three spaces, `GMT',
# `Unrecognized/Unrecognized', or possibly the
# empty string, depending on what system we are
# running on. With any luck, this will catch any
# other existing variations as well. The way it is
# used later does have the disadvantage of
# rejecting at least the `Europe/London' timezone
# for half the year when $UTZ gets set to `GMT',
# like happens on NetBSD, but, since I haven't
# come up with any better ideas and since
# rejecting a timezone just causes a few tests to
# be skipped, this will have to do for now.
#
# UTZ stands for Unrecognized Time Zone.
UTZ=`TZ=Unrecognized/Unrecognized date +%Z`

# The following function will return true if $1 is
# a valid timezone. It will return false and set
# $skipreason, otherwise.
#
# Clobbers $NTZ & $skipreason.
#
# SUS2 says `date +%Z' will return `no characters'
# if `no timezone is determinable'. It is,
# unfortunately, not very specific about what
# `determinable' means. On GNU/Linux, `date +%Z'
# returns $TZ when $TZ is not recognized. NetBSD
# 1.6.1 "determines" that an unrecognizable value
# in $TZ really means `GMT'. On Cray, the standard
# is ignored and `date +%Z' returns three spaces
# when $TZ is not recognized. We test for all
# three cases, plus the empty string for good
# measure, though I know of no set of conditions
# which will actually cause `date +%Z' to return
# the empty string SUS2 specifies.
#
# Due to the current nature of this test, this
# will not work for the three-letter zone codes on
# some systems. e.g.:
#
#   test `TZ=EST date +%Z` = "EST"
#
# should, quite correctly, evaluate to true on
# most systems, but:
#
#   TZ=Asia/Calcutta date +%Z
#
# would return `IST' on GNU/Linux, and hopefully
# any system which understands the `Asia/Calcutta'
# timezone, and ` ' on Cray. Similarly:
#
#   TZ=Doesnt_Exist/Doesnt_Exist date +%Z
#
# returns `Doesnt_Exist/Doesnt_Exist' on GNU/Linux
# and ` ' on Cray.
#
# Unfortunately, the %z date format string (-HHMM
# format time zone) supported by the GNU `date'
# command is not part of any standard I know of
# and, therefore, is probably not portable.
#
valid_timezone ()
{
  NTZ=`TZ=$1 date +%Z`
  if test "$NTZ" = "$UTZ" || test "$NTZ" = "$1"; then
skipreason="$1 is not a recognized timezone on this system"
return `false`
  else
return `:`
  fi
}

if valid_timezone ${1+"$@"}; then
  echo valid_timezone ${1+"$@"} = true
else
  echo valid_timezone ${1+"$@"} = false
fi
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFCYDp73x41pRYZE/gRAmk8AKDShDDwjjuZpanN7cfpVLJECqmcPACgxdvu
FJs7VStollRoIU/QR+2cgX8=
=CfdJ
-END PGP SIGNATURE-


___
Bug-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: get_date returning false

2005-04-15 Thread Derek Price 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark D. Baushke wrote:

> So, for unrecognized zones, three spaces are produced for the
> timezone on the CRAY Y-MP system.


Hrm.  `date +%Z' returns `GMT' on my NetBSD 1.6.1.  I think this will
not be easy, especially as one of the timezones suggested by Ian's
tests was Europe/London, which really _does_ fall into GMT part of the
year.

bash-2.05$ uname -a
NetBSD strength.ximbiot.com 1.6.1 NetBSD 1.6.1 (GENERIC) #0: Tue Apr
8 12:05:52 UTC 2003
[EMAIL 
PROTECTED]:/autobuild/netbsd-1-6/i386/OBJ/autobuild/netbsd-1-6/src/sys/arch/i386/compile/GENERIC
i386
bash-2.05$ TZ=Asia/Calcutta date +%Z
IST
bash-2.05$ TZ=Asia/Unrecognized date +%Z
GMT
bash-2.05$



Okay, I came up with and committed the attached.  Run on platforms
where `TZ=Unrecognized date +%Z' returns `GMT' yet `Europe/London' is
a recognized timezone, like NetBSD, it will skip one set of tests
during portions of the year when Europe/London is in GMT, but the
tests should run or be skipped properly on other platforms and in the
summer on BSD.

If anyone thinks it is worth spending more time on this, they are
welcome to do so.  :)

Regards,

Derek


# Prep for future calls to valid_timezone().
#
# This should set $UTZ to three spaces, `GMT',
`Unrecognized/Unrecognized', or
# possibly the empty string, depending on what system we are running
on.  With
# any luck, this will catch any other existing variations as well.
The way it
# is used later does have the disadvantage of rejecting at least the
# `Europe/London' timezone for half the year when $UTZ gets set to
`GMT', like
# happens on NetBSD, but, since I haven't come up with any better
ideas and
# since rejecting a timezone just causes a few tests to be skipped,
this will
# have to do for now.
#
# UTZ stands for Unrecognized Time Zone.
UTZ=`TZ=Unrecognized/Unrecognized date +%Z`

# The following function will return true if $1 is a valid timezone.
It will
# return false and set $skipreason, otherwise.
#
# Clobbers $NTZ & $skipreason.
#
# SUS2 says `date +%Z' will return `no characters' if `no timezone is
# determinable'.  It is, unfortunately, not very specific about what
# `determinable' means.  On GNU/Linux, `date +%Z' returns $TZ when $TZ
is not
# recognized.  NetBSD 1.6.1 "determines" that an unrecognizable value
in $TZ
# really means `GMT'.  On Cray, the standard is ignored and `date +%Z'
returns
# three spaces when $TZ is not recognized.  We test for all three
cases, plus
# the empty string for good measure, though I know of no set of conditions
# which will actually cause `date +%Z' to return the empty string SUS2
# specifies.
#
# Due to the current nature of this test, this will not work for the
# three-letter zone codes on some systems.  e.g.:
#
#   test `TZ=EST date +%Z` = "EST"
#
# should, quite correctly, evaluate to true on most systems, but:
#
#   TZ=Asia/Calcutta date +%Z
#
# would return `IST' on GNU/Linux, and hopefully any system which
understands
# the `Asia/Calcutta' timezone, and `   ' on Cray.  Similarly:
#
#   TZ=Doesnt_Exist/Doesnt_Exist date +%Z
#
# returns `Doesnt_Exist/Doesnt_Exist' on GNU/Linux and `   ' on Cray.
#
# Unfortunately, the %z date format string (-HHMM format time zone)
supported
# by the GNU `date' command is not part of any standard I know of and,
# therefore, is probably not portable.
#
valid_timezone ()
{
NTZ=`TZ=$1 date +%Z`
if test "$NTZ" = "$UTZ" || test "$NTZ" = "$1"; then
skipreason="$1 is not a recognized timezone on this
system"
return `false`
else
return `:`
fi
}

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCYC6rLD1OTBfyMaQRAscSAJ9xZwcRRIYLWX9QMCK24xeJBwbOWACg702O
nsxY3Z0u7Xirj0FQ1iAtULk=
=f3sm
-END PGP SIGNATURE-




___
Bug-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: get_date returning false

2005-04-15 Thread Mark D. Baushke 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Derek Price <[EMAIL PROTECTED]> writes:

> Mark D. Baushke wrote:
> 
> > [EMAIL PROTECTED] mdb]$ export TZ=Asia/Calcutta [EMAIL PROTECTED] mdb]$ 
> > date Fri Apr
> > 15 07:01:59 2005
> 
> 
> ...
> 
> > [EMAIL PROTECTED] mdb]$ TZ=Pacific/Honolulu date Fri Apr 15 07:07:12
> > 2005 [EMAIL PROTECTED] mdb]$
> >
> > That said, I doubt if this will be a big problem given that CRAY
> > doesn't yet support client/server as I have only been able to get
> > :local: to work on it.
> 
> 
> Hrm.  Does the Cray exhibit similar behavior to the following for
> unrecognized time zones?  The POSIX spec doesn't really seem to specify...
> 
> [EMAIL PROTECTED] ccvs-merge]$ date +%Z
> EDT
> [EMAIL PROTECTED] ccvs-merge]$ TZ=Asia/Calcutta date +%Z
> IST
> [EMAIL PROTECTED] ccvs-merge]$ TZ=Asia/Garbage date +%Z
> Asia/Garbage
> [EMAIL PROTECTED] ccvs-merge]$
> 
> 
> I could write a simple test and skip the TZ dependent tests when
> `TZ=REGION/CITY date +%Z` = "REGION/CITY".

[EMAIL PROTECTED] mdb]$ date +%Z
MET
[EMAIL PROTECTED] mdb]$ TZ=Asia/Calcutta date +%Z
   
[EMAIL PROTECTED] mdb]$ TZ=Asia/Garbage date +%Z
   
[EMAIL PROTECTED] mdb]$ AAA=`TZ=Asia/Garbage date +%Z`;echo "'$AAA'"
'   '
[EMAIL PROTECTED] mdb]$ AAA=`TZ=Asia/Calcutta date +%Z` ; echo "'$AAA'"
'   '
[EMAIL PROTECTED] mdb]$ AAA=`TZ=Asia/Calcutta date +%Z` ; echo "'$AAA'" > i
[EMAIL PROTECTED] mdb]$ od i
0 023440 020040 023412
6
[EMAIL PROTECTED] mdb]$ AAA=`TZ=Asia/Garbage date +%Z`; echo "'$AAA'" > i
[EMAIL PROTECTED] mdb]$ od i
0 023440 020040 023412
6
[EMAIL PROTECTED] mdb]$ AAA=`date +%Z`; echo "'$AAA'" > i
[EMAIL PROTECTED] mdb]$ od i
0 023515 042524 023412
6
[EMAIL PROTECTED] mdb]$ cat i
'MET'
[EMAIL PROTECTED] mdb]$ uname -a
sn5176 sn5176 9.0.2.2 sin.0 CRAY Y-MP
[EMAIL PROTECTED] mdb]$ 

So, for unrecognized zones, three spaces are produced for the timezone
on the CRAY Y-MP system.

-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFCX98N3x41pRYZE/gRAnG1AJ9Ic3A1ggXKAzk3tdS1NrokRYGnvACeMEDb
2JIXiXtjIiXZf8w8rNDFAM0=
=APyc
-END PGP SIGNATURE-


___
Bug-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: get_date returning false

2005-04-15 Thread Derek Price 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark D. Baushke wrote:

> [EMAIL PROTECTED] mdb]$ export TZ=Asia/Calcutta [EMAIL PROTECTED] mdb]$ date 
> Fri Apr
> 15 07:01:59 2005


...

> [EMAIL PROTECTED] mdb]$ TZ=Pacific/Honolulu date Fri Apr 15 07:07:12
> 2005 [EMAIL PROTECTED] mdb]$
>
> That said, I doubt if this will be a big problem given that CRAY
> doesn't yet support client/server as I have only been able to get
> :local: to work on it.


Hrm.  Does the Cray exhibit similar behavior to the following for
unrecognized time zones?  The POSIX spec doesn't really seem to specify...

[EMAIL PROTECTED] ccvs-merge]$ date +%Z
EDT
[EMAIL PROTECTED] ccvs-merge]$ TZ=Asia/Calcutta date +%Z
IST
[EMAIL PROTECTED] ccvs-merge]$ TZ=Asia/Garbage date +%Z
Asia/Garbage
[EMAIL PROTECTED] ccvs-merge]$


I could write a simple test and skip the TZ dependent tests when
`TZ=REGION/CITY date +%Z` = "REGION/CITY".

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCX9L8LD1OTBfyMaQRAjgYAKCIjhFKYAYYQ56ioOZ4BwR5LfI9jACfT0Xf
ujWFAFVkOBJLyNWEs7Eo6is=
=dTgy
-END PGP SIGNATURE-




___
Bug-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: get_date returning false

2005-04-15 Thread Mark D. Baushke 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Derek Price <[EMAIL PROTECTED]> writes:

> Ian Abbott wrote:
> 
> | Hi Derek,
> |
> | On 08/04/05 19:05, you wrote:
> |
> |> Is there some simple, cross-platform test I could use to fall
> |> back on GMT0BST,M3.5.0,M10.5.0 if the Europe/London timezone
> |> isn't defined or skip the tests entirely if neither zone is
> |> enabled?
> |
> |
> | No idea, sorry.  Hopefully it won't matter unless the internal use
> | of GMT creaps back in!
> 
> 
> Anybody have any idea how many platforms won't support the
> Large_Place/City timezone format?  Mark?  Larry?  Should I check in
> some new tests and see how many nightly test platforms break?  I could
> always back them out again.

I think most of my platforms will work fine (FreeBSD 4.x, GNU/Linux,
Solaris, MacOS X). I am not sure about the CRAY... Let me see:

ssh login.cray-cyber.org


##
#   Welcome to yel.cray-cyber.org#
# This is a Cray Y/MP EL with 4 CPUs and 1 GB RAM running UNICOS 9.0 #
##
#  For more information about this machine, see the website  #
#  By logging on, you agree to the terms of usage which can be found #
#  under http://www.cray-cyber.org/access/terms.php  #
##


[EMAIL PROTECTED] mdb]$ echo $TZ
MET-1MET,M3.5.0,M10.5.0
[EMAIL PROTECTED] mdb]$ export TZ=Asia/Calcutta 
[EMAIL PROTECTED] mdb]$ date
Fri Apr 15 07:01:59 2005
[EMAIL PROTECTED] mdb]$ export TZ=MET-1MET,M3.5.0,M10.5.0
[EMAIL PROTECTED] mdb]$ date
Fri Apr 15 09:02:13 MET 2005
[EMAIL PROTECTED] mdb]$ 

Let me see what the man page for environ has to say about TZ

[EMAIL PROTECTED] mdb]$ man -s 7 environ
...
TZTime zone information.  The format is xxxnzzz where xxx is
   standard local time zone abbreviation, n is the difference
   in hours from GMT, and zzz is the abbreviation for the
   daylight-saving local time zone, if any; for example,
   EST5EDT.
...

[EMAIL PROTECTED] mdb]$ TZ=Pacific/Honolulu date
Fri Apr 15 07:07:12 2005
[EMAIL PROTECTED] mdb]$ 

That said, I doubt if this will be a big problem given that CRAY doesn't
yet support client/server as I have only been able to get :local: to
work on it.

-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFCX2kX3x41pRYZE/gRAv2OAKDECR+JK1WE/FasJqigHvsvCzklegCeNZDL
K893bsLln1IzWscZc8cLK+c=
=DJA9
-END PGP SIGNATURE-


___
Bug-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: get_date returning false

2005-04-08 Thread Derek Price 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Abbott wrote:
| Hi Derek,
|
| On 08/04/05 19:05, you wrote:
|
|> Is there some simple, cross-platform test I could use to fall
|> back on GMT0BST,M3.5.0,M10.5.0 if the Europe/London timezone
|> isn't defined or skip the tests entirely if neither zone is
|> enabled?
|
|
| No idea, sorry.  Hopefully it won't matter unless the internal use
| of GMT creaps back in!
Anybody have any idea how many platforms won't support the
Large_Place/City timezone format?  Mark?  Larry?  Should I check in
some new tests and see how many nightly test platforms break?  I could
always back them out again.
Cheers,
Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCVuuHLD1OTBfyMaQRAgtDAKDp4bZG4q2reDQqvmzt3xdmT1sQtQCgspkI
nK87dKZ7bGRM7abSMnxdtO0=
=HLnC
-END PGP SIGNATURE-

___
Bug-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: get_date returning false

2005-04-08 Thread Ian Abbott 
On 08/04/05 19:16, Derek Price wrote:
I've checked in a workaround on 1.12.x - I've replaced all three
remaining internal references to "GMT" in the sources with "-".
Let me know if this works for you, and it can be released with
1.12.12.  I don't know whether to expect a getdate fix from GNULIB
yet, but if we do, then I'll roll that in too.
Yes, "cvs diff -u" is now working for me.  I tried it with the following 
TZ settings: "GMT", "GMT0", "BST-1", "GMT0BST", 
"GMT0BST,M3.5.0,M10.5.0", "Europe/London", "foobar".  (Glibc defaulted 
to UTC when I used "foobar"!)

--
-=( Ian Abbott @ MEV Ltd.E-mail: <[EMAIL PROTECTED]>)=-
-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587 )=-
___
Bug-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: get_date returning false

2005-04-08 Thread Derek Price 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Abbott wrote:
| Hi Derek,
|
| I've tried building getdate in cvs-1.12.11 and in ccvs from the
| repository.  I got the same result in both cases.
|
| If you want to try and reproduce it, you'll probably need to set
| the TZ environment variable.  Mine is set to "Europe/London", but
| if your libc doesn't understand that format, you can try
| "GMT0BST,M3.5.0,M10.5.0" or "GMT0BST" instead.
|
| Here is the result of some of my tests:
|
| $ TZ=Europe/London ./getdate Enter date, or blank line to exit.
|> 2005-4-1 GMT
| Bad format - couldn't convert.
|> 2005-3-31 GMT
| Bad format - couldn't convert.
|> 2005-3-30 GMT
| Bad format - couldn't convert.
|> 2005-4-1 BST
| 2005-04-01 00:00:00.0
|> $
| $ TZ=America/New_York ./getdate Enter date, or blank line to exit.
|> 2005-4-1 GMT
| 2005-03-31 19:00:00.0
|> 2005-4-2 GMT
| 2005-04-01 19:00:00.0
It looks like zones which have a summer daylight counterpart are
failing.  These same dates passed as "EST" fail, though "EDT" passes.
I assume this is what we are seeing with the successful parsing of
Ian's "BST" (British Summer Time):
$ TZ=America/New_York ./getdate >getdate-got
Enter date, or blank line to exit.
~> 2005-3-1 EST
2005-03-01 00:00:00.0
~> 2005-4-1 EST
2005-04-01 00:00:00.0
~> 2005-5-1 EST
Bad format - couldn't convert.
~> 2005-5-1 EDT
2005-05-01 00:00:00.0
~> 2005-5-1 UTC0
2005-04-30 20:00:00.0
~> 2005-6-1 EST
Bad format - couldn't convert.
~> 2005-6-1 EDT
2005-06-01 00:00:00.0
~> 2005-6-1 UTC0
2005-05-31 20:00:00.0
~>
I've checked in a workaround on 1.12.x - I've replaced all three
remaining internal references to "GMT" in the sources with "-".
Let me know if this works for you, and it can be released with
1.12.12.  I don't know whether to expect a getdate fix from GNULIB
yet, but if we do, then I'll roll that in too.
Regards,
Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCVsp+LD1OTBfyMaQRAnjdAKCv3DhIBSCRYoAUpgEuHdL017tkIwCgzw3d
qPT1vZNu3ergz7kD734cG+4=
=EK5D
-END PGP SIGNATURE-

___
Bug-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: get_date returning false

2005-04-08 Thread Derek Price 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Abbott wrote:
| On 08/04/2005 16:05, Derek Price wrote:
|
|> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
|>
|> Ian Abbott wrote:
|>
|> | If you want to try and reproduce it, you'll probably need to
|> set | the TZ environment variable. Mine is set to
|> "Europe/London", but if |  your libc doesn't understand that
|> format, you can try | "GMT0BST,M3.5.0,M10.5.0" or "GMT0BST"
|> instead.
|>
|> Is one of these formats likely to be portable?  I could add this
|> to the test suite, then...
|
|
| The TZ environment variable has evolved over the years.  Old Unix
| systems only supported the STD[DST[]] format like
| my "GMT0BST" above, so that format is the most portable, but the
| daylight savings rules are incorrect, except in the US (and
| Canada?).  The "daylight savings rules" part of the TZ variable
| were added in later Unix versions (I first encountered it in IBM
| AIX). If the daylight savings rules section was left off, the
| system defaulted to US daylight savings rules.  The full format is
| described in the tzset(3) manpage or the environ(5) manpage (for
| the TZ variable).
|
| The modern "Europe/London" format uses a database of timezone rules
|  over history for each geographic and/or political region.  This is
|  known as the "tz" or "zoneinfo" database and is used in most
| modern Unix systems.  Read more about it here:
| .
Is there some simple, cross-platform test I could use to fall back on
GMT0BST,M3.5.0,M10.5.0 if the Europe/London timezone isn't defined or
skip the tests entirely if neither zone is enabled?
Regards,
Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCVsf9LD1OTBfyMaQRAuKVAKChyBgUWlHWxRgelTdWtOC/Kkm+/QCglWoS
/58CgqNCha1jO3hXOwKbQJY=
=Rb0u
-END PGP SIGNATURE-

___
Bug-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: get_date returning false

2005-04-08 Thread Ian Abbott 
On 08/04/2005 16:05, Derek Price wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Abbott wrote:
| If you want to try and reproduce it, you'll probably need to set
| the TZ environment variable. Mine is set to "Europe/London", but if
|  your libc doesn't understand that format, you can try
| "GMT0BST,M3.5.0,M10.5.0" or "GMT0BST" instead.
Is one of these formats likely to be portable?  I could add this to
the test suite, then...
The TZ environment variable has evolved over the years.  Old Unix 
systems only supported the STD[DST[]] format like my 
"GMT0BST" above, so that format is the most portable, but the daylight 
savings rules are incorrect, except in the US (and Canada?).  The 
"daylight savings rules" part of the TZ variable were added in later 
Unix versions (I first encountered it in IBM AIX).  If the daylight 
savings rules section was left off, the system defaulted to US daylight 
savings rules.  The full format is described in the tzset(3) manpage or 
the environ(5) manpage (for the TZ variable).

The modern "Europe/London" format uses a database of timezone rules over 
history for each geographic and/or political region.  This is known as 
the "tz" or "zoneinfo" database and is used in most modern Unix systems. 
 Read more about it here: .

--
-=( Ian Abbott @ MEV Ltd.E-mail: <[EMAIL PROTECTED]>)=-
-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587 )=-
___
Bug-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: get_date returning false

2005-04-08 Thread Derek Price 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Abbott wrote:
| If you want to try and reproduce it, you'll probably need to set
| the TZ environment variable. Mine is set to "Europe/London", but if
|  your libc doesn't understand that format, you can try
| "GMT0BST,M3.5.0,M10.5.0" or "GMT0BST" instead.
Is one of these formats likely to be portable?  I could add this to
the test suite, then...
Regards,
Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCVp2hLD1OTBfyMaQRAl6hAJ9pV8l2okEtAj/5uOesd5VZlXRRygCfXQVa
E6QR+2IyYGqBKkdoypqTzHY=
=z/Uw
-END PGP SIGNATURE-

___
Bug-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: get_date returning false

2005-04-08 Thread Ian Abbott 
Hi Derek,
I've tried building getdate in cvs-1.12.11 and in ccvs from the 
repository.  I got the same result in both cases.

If you want to try and reproduce it, you'll probably need to set the TZ 
environment variable.  Mine is set to "Europe/London", but if your libc 
doesn't understand that format, you can try "GMT0BST,M3.5.0,M10.5.0" or 
"GMT0BST" instead.

Here is the result of some of my tests:
$ TZ=Europe/London ./getdate
Enter date, or blank line to exit.
> 2005-4-1 GMT
Bad format - couldn't convert.
> 2005-3-31 GMT
Bad format - couldn't convert.
> 2005-3-30 GMT
Bad format - couldn't convert.
> 2005-4-1 BST
2005-04-01 00:00:00.0
> $
$ TZ=America/New_York ./getdate
Enter date, or blank line to exit.
> 2005-4-1 GMT
2005-03-31 19:00:00.0
> 2005-4-2 GMT
2005-04-01 19:00:00.0
> $
$ TZ=Europe/Kiev ./getdate
Enter date, or blank line to exit.
> 2005-4-1 GMT
2005-04-01 03:00:00.0
> $
$
As you can see, this problem only seems to affect the British (and the 
Irish, as TZ=Europe/Dublin exhibited the same problem).

I'll try reporting the bug to [EMAIL PROTECTED]
Cheers,
Ian.
On 07/04/05 19:05, Derek Price wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The correct place to report bugs in the getdate library would be
[EMAIL PROTECTED], but could you please verify that you can reproduce
your problem with the version of CVS available from the CVS repository
on cvshome.org before you bother them?  Also, see if you can `cd lib;
make getdate; ./getdate' and then enter your offending date at the
prompt provided.  I cannot reproduce the problem you report using this
method, which might imply a problem with how we are using get_date
rather than with get_date itself, but then you should not have seen
problems from yyparse...  anyway, please let us know what you discover.
Regards,
Derek
Ian Abbott wrote:
| Hi,
|
| I've just started having a problem with "cvs date -u" (version
| 1.12.11):
|
|
| cvs diff: Diffing . Index: ChangeLog cvs diff: internal error: bad
| date 7 Apr 2005 11:50:26 -
| ===
|  RCS file: /work/abbotti/Repository/ampser/ChangeLog,v retrieving
| revision 1.66 *** glibc detected *** malloc(): memory corruption:
| 0x080eff60 *** cvs [diff aborted]: received abort signal
|
|
| I think the memory corruption is a side effect of the "bad date",
| so I'm concentrating on that for now.  I've traced the problem as
| far as the 'get_date' function, called from 'RCS_getrevtime'.
| 'get_date' returned 'false', so 'RCS_getrevtime' never got as far
| as filling in the 'date' string for its caller.
|
| Some debugging info from gdb follows 
|
| Value of 'pc' prior to the call to 'yyparse':
|
| (gdb) p pc $39 = {input = 0xbfffebe0 "2005-4-7 GMT 11:36:56",
| day_ordinal = 1073837632, day_number = 1075498996, local_isdst =
| -1073747276, time_zone = -1073747304, meridian = 2, year = {value =
| 2005, digits = 4}, month = 4, day = 7, hour = 14, minutes = 57,
| seconds = {tv_sec = 7, tv_nsec = 27359}, rel_year = 0,
| rel_month = 0, rel_day = 0, rel_hour = 0, rel_minutes = 0,
| rel_seconds = 0, rel_ns = 0, timespec_seen = false, dates_seen = 0,
| days_seen = 0, local_zones_seen = 0, rels_seen = 0, times_seen = 0,
| zones_seen = 0, local_time_zone_table = {{ name = 0x80e3fb8 "BST",
| type = 264, value = 1}, { name = 0x80e4a70 "GMT", type = 264, value
| = 0}, { name = 0x0, type = 0, value = 0}}}
|
| Value of 'pc' after the call to 'yyparse':
|
| (gdb) p pc $40 = {input = 0xbfffebf6
|
"[EMAIL PROTECTED]@\u\u\032@(\u\u\uO\u\016@ 

|  [EMAIL PROTECTED]", day_ordinal = 1073837632, day_number = 1075498996,
| local_isdst = 0, time_zone = -1073747304, meridian = 2, year =
| {value = 2005, digits = 4}, month = 4, day = 7, hour = 11, minutes
| = 36, seconds = {tv_sec = 56, tv_nsec = 0}, rel_year = 0, rel_month
| = 0, rel_day = 0, rel_hour = 0, rel_minutes = 0, rel_seconds = 0,
| rel_ns = 0, timespec_seen = false, dates_seen = 1, days_seen = 0,
| local_zones_seen = 1, rels_seen = 0, times_seen = 1, zones_seen =
| 0, local_time_zone_table = {{ name = 0x80e3fb8 "BST", type = 264,
| value = 1}, { name = 0x80e4a70 "GMT", type = 264, value = 0}, {
| name = 0x0, type = 0, value = 0}}}
|
| Values of 'Start', 'tm0' and 'tm' after the call to 'mktime':
|
| (gdb) p Start $46 = 1112873816 (gdb) p tm0 $47 = {tm_sec = 56,
| tm_min = 36, tm_hour = 11, tm_mday = 7, tm_mon = 3, tm_year = 105,
| tm_wday = 1075497952, tm_yday = 0, tm_isdst = 0, tm_gmtoff =
| 1075498996, tm_zone = 0x0} (gdb) p tm $48 = {tm_sec = 56, tm_min =
| 36, tm_hour = 12, tm_mday = 7, tm_mon = 3, tm_year = 105, tm_wday =
| 4, tm_yday = 96, tm_isdst = 1, tm_gmtoff = 3600, tm_zone =
| 0x80e3fb8 "BST"}
|
| The following call to 'mktime_ok' returns 0 because tm_hour has
| changed.  This causes 'get_time' to 'goto fail' and return 'false'
| because pc.zones_seen == 0.
|
| Ho

Re: get_date returning false

2005-04-07 Thread Derek Price 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The correct place to report bugs in the getdate library would be
[EMAIL PROTECTED], but could you please verify that you can reproduce
your problem with the version of CVS available from the CVS repository
on cvshome.org before you bother them?  Also, see if you can `cd lib;
make getdate; ./getdate' and then enter your offending date at the
prompt provided.  I cannot reproduce the problem you report using this
method, which might imply a problem with how we are using get_date
rather than with get_date itself, but then you should not have seen
problems from yyparse...  anyway, please let us know what you discover.
Regards,
Derek
Ian Abbott wrote:
| Hi,
|
| I've just started having a problem with "cvs date -u" (version
| 1.12.11):
|
|
| cvs diff: Diffing . Index: ChangeLog cvs diff: internal error: bad
| date 7 Apr 2005 11:50:26 -
| ===
|  RCS file: /work/abbotti/Repository/ampser/ChangeLog,v retrieving
| revision 1.66 *** glibc detected *** malloc(): memory corruption:
| 0x080eff60 *** cvs [diff aborted]: received abort signal
|
|
| I think the memory corruption is a side effect of the "bad date",
| so I'm concentrating on that for now.  I've traced the problem as
| far as the 'get_date' function, called from 'RCS_getrevtime'.
| 'get_date' returned 'false', so 'RCS_getrevtime' never got as far
| as filling in the 'date' string for its caller.
|
| Some debugging info from gdb follows 
|
| Value of 'pc' prior to the call to 'yyparse':
|
| (gdb) p pc $39 = {input = 0xbfffebe0 "2005-4-7 GMT 11:36:56",
| day_ordinal = 1073837632, day_number = 1075498996, local_isdst =
| -1073747276, time_zone = -1073747304, meridian = 2, year = {value =
| 2005, digits = 4}, month = 4, day = 7, hour = 14, minutes = 57,
| seconds = {tv_sec = 7, tv_nsec = 27359}, rel_year = 0,
| rel_month = 0, rel_day = 0, rel_hour = 0, rel_minutes = 0,
| rel_seconds = 0, rel_ns = 0, timespec_seen = false, dates_seen = 0,
| days_seen = 0, local_zones_seen = 0, rels_seen = 0, times_seen = 0,
| zones_seen = 0, local_time_zone_table = {{ name = 0x80e3fb8 "BST",
| type = 264, value = 1}, { name = 0x80e4a70 "GMT", type = 264, value
| = 0}, { name = 0x0, type = 0, value = 0}}}
|
| Value of 'pc' after the call to 'yyparse':
|
| (gdb) p pc $40 = {input = 0xbfffebf6
|
"[EMAIL PROTECTED]@\u\u\032@(\u\u\uO\u\016@
|  [EMAIL PROTECTED]", day_ordinal = 1073837632, day_number = 1075498996,
| local_isdst = 0, time_zone = -1073747304, meridian = 2, year =
| {value = 2005, digits = 4}, month = 4, day = 7, hour = 11, minutes
| = 36, seconds = {tv_sec = 56, tv_nsec = 0}, rel_year = 0, rel_month
| = 0, rel_day = 0, rel_hour = 0, rel_minutes = 0, rel_seconds = 0,
| rel_ns = 0, timespec_seen = false, dates_seen = 1, days_seen = 0,
| local_zones_seen = 1, rels_seen = 0, times_seen = 1, zones_seen =
| 0, local_time_zone_table = {{ name = 0x80e3fb8 "BST", type = 264,
| value = 1}, { name = 0x80e4a70 "GMT", type = 264, value = 0}, {
| name = 0x0, type = 0, value = 0}}}
|
| Values of 'Start', 'tm0' and 'tm' after the call to 'mktime':
|
| (gdb) p Start $46 = 1112873816 (gdb) p tm0 $47 = {tm_sec = 56,
| tm_min = 36, tm_hour = 11, tm_mday = 7, tm_mon = 3, tm_year = 105,
| tm_wday = 1075497952, tm_yday = 0, tm_isdst = 0, tm_gmtoff =
| 1075498996, tm_zone = 0x0} (gdb) p tm $48 = {tm_sec = 56, tm_min =
| 36, tm_hour = 12, tm_mday = 7, tm_mon = 3, tm_year = 105, tm_wday =
| 4, tm_yday = 96, tm_isdst = 1, tm_gmtoff = 3600, tm_zone =
| 0x80e3fb8 "BST"}
|
| The following call to 'mktime_ok' returns 0 because tm_hour has
| changed.  This causes 'get_time' to 'goto fail' and return 'false'
| because pc.zones_seen == 0.
|
| Hopefully, there's enough info there for some bright spark to spot
| the problem, but let me know if you need more info.
|
| Cheers, Ian.
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCVXZ3LD1OTBfyMaQRAjRGAJ9TS6wpLPGB0GL6q7ut3uv7cKoqdACg1iUR
ffyBVz1ylkvO8wyUk7rlx/Q=
=4OnW
-END PGP SIGNATURE-

___
Bug-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-cvs

get_date returning false

2005-04-07 Thread Ian Abbott 
Hi,
I've just started having a problem with "cvs date -u" (version 1.12.11):
cvs diff: Diffing .
Index: ChangeLog
cvs diff: internal error: bad date 7 Apr 2005 11:50:26 -
===
RCS file: /work/abbotti/Repository/ampser/ChangeLog,v
retrieving revision 1.66
*** glibc detected *** malloc(): memory corruption: 0x080eff60 ***
cvs [diff aborted]: received abort signal
I think the memory corruption is a side effect of the "bad date", so I'm 
concentrating on that for now.  I've traced the problem as far as the 
'get_date' function, called from 'RCS_getrevtime'.  'get_date' returned 
'false', so 'RCS_getrevtime' never got as far as filling in the 'date' 
string for its caller.

Some debugging info from gdb follows 
Value of 'pc' prior to the call to 'yyparse':
(gdb) p pc
$39 = {input = 0xbfffebe0 "2005-4-7 GMT 11:36:56",
  day_ordinal = 1073837632, day_number = 1075498996,
  local_isdst = -1073747276, time_zone = -1073747304, meridian = 2,
  year = {value = 2005, digits = 4}, month = 4, day = 7, hour = 14,
  minutes = 57, seconds = {tv_sec = 7, tv_nsec = 27359},
  rel_year = 0, rel_month = 0, rel_day = 0, rel_hour = 0,
  rel_minutes = 0, rel_seconds = 0, rel_ns = 0, timespec_seen = false,
  dates_seen = 0, days_seen = 0, local_zones_seen = 0, rels_seen = 0,
  times_seen = 0, zones_seen = 0, local_time_zone_table = {{
  name = 0x80e3fb8 "BST", type = 264, value = 1}, {
  name = 0x80e4a70 "GMT", type = 264, value = 0}, {
  name = 0x0, type = 0, value = 0}}}
Value of 'pc' after the call to 'yyparse':
(gdb) p pc
$40 = {input = 0xbfffebf6 
"[EMAIL PROTECTED]@\u\u\032@(\u\u\uO\u\016@ 
[EMAIL PROTECTED]",
  day_ordinal = 1073837632, day_number = 1075498996, local_isdst = 0,
  time_zone = -1073747304, meridian = 2, year = {value = 2005,
digits = 4}, month = 4, day = 7, hour = 11, minutes = 36,
  seconds = {tv_sec = 56, tv_nsec = 0}, rel_year = 0, rel_month = 0,
  rel_day = 0, rel_hour = 0, rel_minutes = 0, rel_seconds = 0,
  rel_ns = 0, timespec_seen = false, dates_seen = 1, days_seen = 0,
  local_zones_seen = 1, rels_seen = 0, times_seen = 1, zones_seen = 0,
  local_time_zone_table = {{
  name = 0x80e3fb8 "BST", type = 264, value = 1}, {
  name = 0x80e4a70 "GMT", type = 264, value = 0}, {
  name = 0x0, type = 0, value = 0}}}

Values of 'Start', 'tm0' and 'tm' after the call to 'mktime':
(gdb) p Start
$46 = 1112873816
(gdb) p tm0
$47 = {tm_sec = 56, tm_min = 36, tm_hour = 11, tm_mday = 7, tm_mon = 3,
  tm_year = 105, tm_wday = 1075497952, tm_yday = 0, tm_isdst = 0,
  tm_gmtoff = 1075498996, tm_zone = 0x0}
(gdb) p tm
$48 = {tm_sec = 56, tm_min = 36, tm_hour = 12, tm_mday = 7, tm_mon = 3,
  tm_year = 105, tm_wday = 4, tm_yday = 96, tm_isdst = 1,
  tm_gmtoff = 3600, tm_zone = 0x80e3fb8 "BST"}
The following call to 'mktime_ok' returns 0 because tm_hour has changed. 
 This causes 'get_time' to 'goto fail' and return 'false' because 
pc.zones_seen == 0.

Hopefully, there's enough info there for some bright spark to spot the 
problem, but let me know if you need more info.

Cheers,
Ian.
--
-=( Ian Abbott @ MEV Ltd.E-mail: <[EMAIL PROTECTED]>)=-
-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587 )=-
___
Bug-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-cvs