Bug#271428: Processed: your mail
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
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
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
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. If people really want to use oddball timezones there is a simple procedure for adding a new zoneinfo file. 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. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#271428: Processed: your mail
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? > If people really want to use oddball timezones there is a simple > procedure for adding a new zoneinfo file. Why don't you think people should check using tzselect and so on? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#271428: Processed: your mail
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
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
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
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
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
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]
