Re: cygcheck's understanding of TZ

2011-06-14 Thread Lee Maschmeyer
Aren't standard TZ names contained in the /usr/share/zoneinfo structure? In that directory I see posix/Europe/Monaco. So I set: $ export TZ=Europe/Monaco $ date 16:46:08 CEST; Tuesday, June 14, 2011 $ export TZ=America/Detroit $ date 10:46:48 EDT; Tuesday, June 14, 2011 Except for this using

Re: cygcheck's understanding of TZ

2011-06-14 Thread Christopher Faylor
On Tue, Jun 14, 2011 at 11:03:00AM -0400, Lee Maschmeyer wrote: Aren't standard TZ names contained in the /usr/share/zoneinfo structure? In that directory I see posix/Europe/Monaco. So I set: Apparently you didn't actually read the whole thread here. You really should. cgf -- Problem reports:

Re: cygcheck's understanding of TZ

2011-06-14 Thread Lee Maschmeyer
Apparently you didn't actually read the whole thread here. Apparently I did. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info:

Re: cygcheck's understanding of TZ

2011-06-14 Thread Edward McGuire
On 6/14/2011 12:30 PM, Lee Maschmeyer wrote: Apparently you didn't actually read the whole thread here. Apparently I did. Then you apparently know the TZ names you posted are not known to cygcheck(1) because they are not in the UNIX standard and that's the only standard it supports. So I

Re: cygcheck's understanding of TZ

2011-06-14 Thread Lee Maschmeyer
Hi Edward, Are you saying that /usr/share/zoneinfo isn't the standard location for all time zone data? And that paths within that directory aren't standard values for TZ? If not, what is? You suggested one value; I suggested another and assumed that either would work as there are lots of

Re: cygcheck's understanding of TZ

2011-06-14 Thread Edward McGuire
On 6/14/2011 1:33 PM, Lee Maschmeyer wrote: Are you saying that /usr/share/zoneinfo isn't the standard location for all time zone data? And that paths within that directory aren't standard values for TZ? If not, what is? There are two standards in play. The UNIX standard recognizes CET-1CEST.

Re: cygcheck's understanding of TZ

2011-06-14 Thread Christopher Faylor
On Tue, Jun 14, 2011 at 01:30:16PM -0400, Lee Maschmeyer wrote: On Tue, Jun 14, 2011 at 11:28:14AM -0400, Christopher Faylor wrote: On Tue, Jun 14, 2011 at 11:03:00AM -0400, Lee Maschmeyer wrote: Aren't standard TZ names contained in the /usr/share/zoneinfo structure? In that directory I see

Re: cygcheck's understanding of TZ

2011-06-14 Thread Christopher Faylor
On Tue, Jun 14, 2011 at 02:19:12PM -0500, Edward McGuire wrote: On 6/14/2011 1:33 PM, Lee Maschmeyer wrote: Are you saying that /usr/share/zoneinfo isn't the standard location for all time zone data? And that paths within that directory aren't standard values for TZ? If not, what is? There

Re: cygcheck's understanding of TZ

2011-06-13 Thread Edward McGuire
On 2011-06-10 16:21, Christopher Faylor wrote: we still have no idea [...] why you find it so crucial for cygcheck to report the date with pinpoint accuracy On Fri, Jun 10, 2011 at 12:44, Denis Excoffier wrote: Wrong by 1h is not pinpoint accuracy (i think). I realize I don't have a vote,

Re: cygcheck's understanding of TZ

2011-06-13 Thread Christopher Faylor
On Mon, Jun 13, 2011 at 10:06:46AM -0500, Edward McGuire wrote: On 2011-06-10 16:21, Christopher Faylor wrote: we still have no idea [...] why you find it so crucial for cygcheck to report the date with pinpoint accuracy On Fri, Jun 10, 2011 at 12:44, Denis Excoffier wrote: Wrong by 1h is not

Re: cygcheck's understanding of TZ

2011-06-10 Thread Denis Excoffier
On 2011-06-09 23:06, Christopher Faylor wrote: We're not changing anything. Having the date there is useful. I (OP) need to use TZ=Europe/Monaco (or similar, or with an absolute name) to make my applications work, including date(1). Currently the `Current System Time' line is: - incorrect

Re: cygcheck's understanding of TZ

2011-06-10 Thread Edward McGuire
On Fri, Jun 10, 2011 at 02:24, Denis Excoffier wrote: I (OP) need to use TZ=Europe/Monaco (or similar, or with an absolute name) to make my applications work, including date(1). TZ=CET-1CEST would be understood by both GNU and MS. -- Problem reports: http://cygwin.com/problems.html FAQ:

Re: cygcheck's understanding of TZ

2011-06-10 Thread Christopher Faylor
On Fri, Jun 10, 2011 at 09:24:45AM +0200, Denis Excoffier wrote: On 2011-06-09 23:06, Christopher Faylor wrote: We're not changing anything. Having the date there is useful. I (OP) need to use TZ=Europe/Monaco (or similar, or with an absolute name) to make my applications work, including

Re: cygcheck's understanding of TZ

2011-06-10 Thread Denis Excoffier
On 2011-06-10 16:21, Christopher Faylor wrote: But, in any event, we still have no idea (since you haven't provided details) why you find it so crucial for cygcheck to report the date with pinpoint accuracy but if this is required for your purposes then you should feel free to provide a

Re: cygcheck's understanding of TZ

2011-06-09 Thread Thomas Wolff
Am 09.06.2011 09:46, schrieb EXCOFFIER Denis: Hello, It seems that /usr/bin/cygcheck does not interpret TZ the same way as /usr/bin/date does, in the case TZ is set to a file name, like in the following example: (under tcsh) jupiter% alias cygdate 'cygcheck -s | head -3' jupiter% (setenv TZ

Re: cygcheck's understanding of TZ

2011-06-09 Thread Edward McGuire
On Thu, Jun 9, 2011 at 02:46, EXCOFFIER Denis denis.excoff...@c-s.fr wrote: It seems that /usr/bin/cygcheck does not interpret TZ the same way as /usr/bin/date does, in the case TZ is set to a file name [snip] jupiter% (setenv TZ /usr/share/zoneinfo/Europe/Monaco; date; cygdate) There are two

RE: cygcheck's understanding of TZ

2011-06-09 Thread Buchbinder, Barry (NIH/NIAID) [E]
Thomas Wolff sent the following at Thursday, June 09, 2011 3:54 AM Am 09.06.2011 09:46, schrieb EXCOFFIER Denis: It seems that /usr/bin/cygcheck does not interpret TZ the same way as /usr/bin/date does, in the case TZ is set to a file name, like in the following example: (under tcsh)

Re: cygcheck's understanding of TZ

2011-06-09 Thread Charles Wilson
On 6/9/2011 1:39 PM, Edward McGuire wrote: So cygcheck(1) is honoring TZ, but it trips over a pathname in a way that date(1) does not. cygcheck.exe is not a cygwin program. It is a native windows program, and thus either (a) uses Windows support for time zone data, not cygwin, or (b) has some

Re: cygcheck's understanding of TZ

2011-06-09 Thread Christopher Faylor
On Thu, Jun 09, 2011 at 12:39:04PM -0500, Edward McGuire wrote: On Thu, Jun 9, 2011 at 02:46, EXCOFFIER Denis denis.excoff...@c-s.fr wrote: It seems that /usr/bin/cygcheck does not interpret TZ the same way as /usr/bin/date does, in the case TZ is set to a file name [snip] jupiter% (setenv TZ

Re: cygcheck's understanding of TZ

2011-06-09 Thread Edward McGuire
On Thu, Jun 9, 2011 at 13:08, Charles Wilson wrote: cygcheck.exe is not a cygwin program.  It is a native windows program, and thus either (a) uses Windows support for time zone data, not cygwin, or (b) has some special code to mimic cygwin's tz handling, which may not be up-to-par.  You'll

Re: cygcheck's understanding of TZ

2011-06-09 Thread Denis Excoffier
On 2011-06-09 21:26, Edward McGuire wrote: cygcheck.cc: [snip] #include sys/time.h [snip] time_t now; [snip] printf (\nCygwin Configuration Diagnostics\n); time (now); printf (Current System Time: %s\n, ctime (now)); It's using C RTL calls. And cygcheck(1) is linked with msvcrt.dll, not

Re: cygcheck's understanding of TZ

2011-06-09 Thread Christopher Faylor
On Thu, Jun 09, 2011 at 09:50:02PM +0200, Denis Excoffier wrote: On 2011-06-09 21:26, Edward McGuire wrote: cygcheck.cc: [snip] #include sys/time.h [snip] time_t now; [snip] printf (\nCygwin Configuration Diagnostics\n); time (now); printf (Current System Time: %s\n, ctime (now));

Re: cygcheck's understanding of TZ

2011-06-09 Thread Edward McGuire
On Thu, Jun 9, 2011 at 16:06, Christopher Faylor wrote: We're not changing anything. Having the date there is useful. Again: you shouldn't use cygcheck -s as a method to find the system date. While strictly true, I doubt that continuing to repeat this caution will be worthwhile. You pointed