From: Jason Green <news AT jgreen4 DOT fsnet DOT co DOT uk>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp AT delorie DOT com
Subject: Re: strftime: Need Help with Time Offsets
Date: Thu, 21 Dec 2000 23:52:44 +0000
Message-ID: <ku454tke181c70f6rimuamfd2pc9p0blfk@4ax.com>
References: <1a524t0tk28cmv3vqfq26tooe0qeikhgm5 AT 4ax DOT com> <Pine DOT SUN DOT 3 DOT 91 DOT 1001221110346 DOT 28580O-100000 AT is>
In-Reply-To: <Pine.SUN.3.91.1001221110346.28580O-100000@is>
X-Mailer: Forte Agent 1.7/32.534
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id SAA22545
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:

> On Wed, 20 Dec 2000, Jason Green wrote:

> > There appears to be a bug in strftime() when using the %z format.
> 
> The bug, whether it exists or not, does not necessarily have anything
> to do with what Felix reported: I replied to his message saying I
> cannot reproduce the problem.  His test program wroked for me.  I

Perhaps you could try my test program too, and tell if it does what
you expect it should?

> > Well, actually not so much a bug as a feature. ;-)
> 
> Actually, %z is undocumented and should not be used at all in the
> DJGPP version of strftime.

Yes, I meant to say "an undocumented feature".  Of course, this could
change if we can agree on what %z should actually do.

> > With existing strftime the test program outputs:
> > 
> > Wed, 20 Dec 2000 20:35:42 +0000 GMT
> > Wed, 20 Dec 2000 20:35:42 +0000 GMT
> > Wed, 20 Dec 2000 08:01:42 -0000 TEST1
> > Thu, 21 Dec 2000 09:09:42 +45240 TEST2
> > 
> > After patching the test program outputs:
> > 
> > Wed, 20 Dec 2000 20:36:21 +0000 GMT
> > Wed, 20 Dec 2000 20:36:21 +0000 GMT
> > Wed, 20 Dec 2000 08:02:21 -1234 TEST1
> > Thu, 21 Dec 2000 09:10:21 +1234 TEST2
> 
> Note that your changes modified the bahavior of %z: it is supposed to
> print the values in seconds, while your version prints it in hours and
> minutes instead.  So this is more than just a bugfix for the negative
> offsets.

Correct.  My previous message wasn't too clear - I'm claiming that for
%z to print seconds is a bug, and the patch is to fix that (as well as
negative offsets).  So this is intentional.

The POSIX Programmer's Guide isn't too helpful on this matter.  It
lists: "%z Time zone.", %Z isn't listed.

The Linux man page for strftime() is better:

       %z     The time-zone as hour offset from GMT.  Required to
              emit  RFC822-conformant  dates (using "%a, %d %b %Y
              %H:%M:%S %z"). (GNU)

       %Z     The time zone or name or abbreviation.

RFC822 says in section 5.1:

     zone        =  "UT"  / "GMT"                ; Universal Time
                                                 ; North American : UT
                 /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
                 /  "CST" / "CDT"                ;  Central:  - 6/ - 5
                 /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
                 /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
                 /  1ALPHA                       ; Military: Z = UT;
                                                 ;  A:-1; (J not used)
                                                 ;  M:-12; N:+1; Y:+12
                 / ( ("+" / "-") 4DIGIT )        ; Local differential
                                                 ;  hours+min. (HHMM)

Here is output from my test program under Linux:

Thu, 21 Dec 2000 23:33:45 +0000 GMT
Thu, 21 Dec 2000 23:33:45 +0000 GMT
Thu, 21 Dec 2000 10:59:45 -1234 TEST1
Fri, 22 Dec 2000 12:07:45 +1234 TEST2

So I think my patch to strftime() makes it behave properly (and at
least gives the behaviour that Felix is looking for).

Of course, %z can be made to do whatever we want.  So if you think it
should do something else please say so and I will try to code for
that.  

Maybe you have a copy of the ANSI standard to check on this?  (I do
not have a copy here).