Bug#271428: Processed: your mail

2004-09-26 Thread GOTO Masanori
At Sun, 26 Sep 2004 07:15:23 -0400,
Michael Stone wrote:
 On Sat, Sep 25, 2004 at 09:19:42PM +0900, GOTO Masanori wrote:
 At Sat, 25 Sep 2004 07:23:27 -0400,
 Michael Stone wrote:
  No, not date. date has nothing to do with this, it's a libc function
  (which is why it's reassigned to libc). I fully agree that *libc* should
  handle the case differently, it's been confusing users for years.
 
 Did you read my mail?
 
 Yes, and it's not the first time you send a mail with no interest in
 people's legitimate concerns without offering a rationale for your own
 position.

 Why don't you think people should check using tzselect and so on?
 
 Because they don't. We've gotten varients of this bug on a regular basis
 for years. The current situation is obviously suboptimal, and obviously
 confuses our users. In general we try to write software such that if
 someone makes a typo the software gives them some indication that
 they've done something wrong so that they can fix it. But in this case
 the software does something completely unexpected and silently gives out
 unexpected data. And so far you haven't given any indication of why you
 think that's a good thing and the proposed solution is a bad thing.

You argument is no sense for me without code.

Regards,
-- gotom






Bug#271428: Processed: your mail

2004-09-26 Thread Michael Stone
On Mon, Sep 27, 2004 at 08:47:04AM +0900, GOTO Masanori wrote:
You argument is no sense for me without code.
That's ridiculous. You can agree or disagree in principle without code.
I can't believe that anyone would waste time coding when you seem so
unwilling to consider changes.
Mike Stone



Bug#271428: Processed: your mail

2004-09-26 Thread GOTO Masanori
At Sun, 26 Sep 2004 20:53:02 -0400,
Michael Stone wrote:
 On Mon, Sep 27, 2004 at 08:47:04AM +0900, GOTO Masanori wrote:
 You argument is no sense for me without code.
 
 That's ridiculous. You can agree or disagree in principle without code.
 I can't believe that anyone would waste time coding when you seem so
 unwilling to consider changes.

Again, it's implementation dependent.  If you disagree, use the
source, Luke.

Regards,
-- gotom




Bug#271428: Processed: your mail

2004-09-25 Thread martin f krafft
also sprach GOTO Masanori [EMAIL PROTECTED] [2004.09.25.0420 +0200]:
Tue Sep 14 06:19:23 Croatia/Split 2004
  
  it should be
  
Tue Sep 14 06:19:23 GMT 2004
 
 Show us your reason of it should be with the standard documents,
 without your opinion.

Oh, whatever. I am not going to search whether this is specified in
the standards. I am talking about common sense here. A line such as 

  Tue Sep 14 06:19:23 Croatia/Split 2004

is just plain wrong. Either date should report an error when the
requested timezone cannot be found, or it should specify which
timezone is at the basis of the date and time it reports.

What it's doing right now is plain wrong, IMHO. Yes, that's my
opinion.

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft [EMAIL PROTECTED]
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature


Bug#271428: Processed: your mail

2004-09-25 Thread GOTO Masanori
At Sat, 25 Sep 2004 11:26:36 +0200,
martin f krafft wrote:
 also sprach GOTO Masanori [EMAIL PROTECTED] [2004.09.25.0420 +0200]:
 Tue Sep 14 06:19:23 Croatia/Split 2004
   
   it should be
   
 Tue Sep 14 06:19:23 GMT 2004
  
  Show us your reason of it should be with the standard documents,
  without your opinion.
 
 Oh, whatever. I am not going to search whether this is specified in
 the standards. I am talking about common sense here. A line such as 
 
   Tue Sep 14 06:19:23 Croatia/Split 2004
 
 is just plain wrong. Either date should report an error when the
 requested timezone cannot be found, or it should specify which
 timezone is at the basis of the date and time it reports.
 
 What it's doing right now is plain wrong, IMHO. Yes, that's my
 opinion.

strftime(3) %Z returns the TZ variable if TZ is not appropriate
character.  SUSv3 says it's implementation-dependent behavior.  Look
at other systems; Solaris also returns like Linux.

I don't want to know you like this form or not because I already knew
it.  There are some reports about it.  OTOH, I want to know changing
to GMT is appropriate thing or not with the C and POSIX specification.

Regards,
-- gotom


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#271428: Processed: your mail

2004-09-25 Thread Michael Stone
On Sat, Sep 25, 2004 at 11:26:36AM +0200, martin f krafft wrote:
Oh, whatever. I am not going to search whether this is specified in
the standards. I am talking about common sense here. A line such as 

 Tue Sep 14 06:19:23 Croatia/Split 2004
is just plain wrong. Either date should report an error when the
requested timezone cannot be found, or it should specify which
timezone is at the basis of the date and time it reports.
No, not date. date has nothing to do with this, it's a libc function
(which is why it's reassigned to libc). I fully agree that *libc* should
handle the case differently, it's been confusing users for years. If
people really want to use oddball timezones there is a simple procedure
for adding a new zoneinfo file.
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]


Bug#271428: Processed: your mail

2004-09-24 Thread GOTO Masanori
At Tue, 14 Sep 2004 08:19:44 +0200,
martin f krafft wrote:
 I failed to make myself clear. No, Croatia/Split is not a correct
 timezone. My point is that `date` then uses GMT, and it should
 display this.
 
 So while the output is:
 
   Tue Sep 14 06:19:23 Croatia/Split 2004
 
 it should be
 
   Tue Sep 14 06:19:23 GMT 2004
 
 Do you see what I mean?

Show us your reason of it should be with the standard documents,
without your opinion.

Regards,
-- gotom


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#271428: Processed: your mail

2004-09-14 Thread martin f krafft
also sprach GOTO Masanori [EMAIL PROTECTED] [2004.09.14.0403 +0200]:
 I don't know Croatia, so please tell me: Can we say
 Croatia/Split is popular timezone?  There's Europe/Zagreb.
 I think you're OK when you use Europe/Zagreb instead.  If you have
 no objection, I'll close this report.

I failed to make myself clear. No, Croatia/Split is not a correct
timezone. My point is that `date` then uses GMT, and it should
display this.

So while the output is:

  Tue Sep 14 06:19:23 Croatia/Split 2004

it should be

  Tue Sep 14 06:19:23 GMT 2004

Do you see what I mean?

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft [EMAIL PROTECTED]
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature


Bug#271428: Processed: your mail

2004-09-13 Thread GOTO Masanori
tags 271428 moreinfo
thanks

 $ TZ=Croatia/Split date
 Mon Sep 13 06:57:13 Croatia/Split 2004
 
 ... when it's really 8:50 there. Croatia/Split does not have
 a zoneinfo entry, so date uses GMT instead. Well, then it should say
 GMT before the year, no? Should be trivial...

I don't know Croatia, so please tell me: Can we say Croatia/Split is
popular timezone?  There's Europe/Zagreb.  I think you're OK when
you use Europe/Zagreb instead.  If you have no objection, I'll close
this report.

Regards,
-- gotom



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]