cygcheck's understanding of TZ

cygcheck's understanding of TZ

[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 /usr/share/zoneinfo/Europe/Monaco; date; cygdate)
Thu Jun  9 09:07:13 CEST 2011

Cygwin Configuration Diagnostics
Current System Time: Thu Jun 09 08:07:14 2011
jupiter%


My ideas:
- /usr/bin/cygcheck has an untypical situation wrt cygwin1.dll
- 'Thu Jun 09 08:07:14 2011' gives no clue about time zone
- 'Current System Time: Thu Jun 09 07:07:14 UTC 2011' would be more
   correct

Regards,

Denis Excoffier.


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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 /usr/share/zoneinfo/Europe/Monaco; date; cygdate)
> Thu Jun  9 09:07:13 CEST 2011

Set TZ to the name of a timezone, not a file name, e.g. (using bash) 
TZ=CET date.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[Edward McGuire]

On Thu, Jun 9, 2011 at 02:46, EXCOFFIER Denis
<denis.excoffier@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 standard syntaxes for TZ. One begins with a timezone
name, the other begins with a colon (:). If you supply a colon, then
the rest of the string is interpreted in an operating system
specific manner. GNU interprets it as a pathname. And Cygwin uses
GNU's time library.

Naïvely, I thought you might just lack a colon on the front of the
pathname. I confirmed time(1) honors the pathname syntax. But
cygcheck(1) mysteriously interprets all pathnames as GMT + 1 hour:

$ TZ=:/usr/share/zoneinfo/US/Central cygcheck -s | head -3 | tail -1
Current System Time: Thu Jun 09 18:23:42 2011
$ TZ=:/usr/share/zoneinfo/Europe/Monaco cygcheck -s | head -3 | tail -1
Current System Time: Thu Jun 09 18:23:49 2011
$ TZ=:/usr/share/zoneinfo/GMT cygcheck -s | head -3 | tail -1
Current System Time: Thu Jun 09 18:23:56 2011
$ TZ=:/usr/share/zoneinfo/Asia/Calcutta cygcheck -s | head -3 | tail -1
Current System Time: Thu Jun 09 18:23:59 2011

It gets local time right:

$ cygcheck -s | head -3 | tail -1
Current System Time: Thu Jun 09 12:25:04 2011

And it gets GMT right:

$ TZ=GMT cygcheck -s | head -3 | tail -1
Current System Time: Thu Jun 09 17:31:32 2011

So cygcheck(1) is honoring TZ, but it trips over a pathname in a
way that date(1) does not.

Cheers,

MetaEd

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: cygcheck's understanding of TZ

[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)
>>
>> jupiter% alias cygdate 'cygcheck -s | head -3'
>> jupiter% (setenv TZ /usr/share/zoneinfo/Europe/Monaco; date; cygdate)
>> Thu Jun  9 09:07:13 CEST 2011
>
>Set TZ to the name of a timezone, not a file name, e.g. (using bash)
>TZ=CET date.

u>Am 09.06.2011 09:46, schrieb EXCOFFIER Denis:

I'm confused.

Using /usr/sbin/tzselect to find TZ ends with the following (questions
have been deleted):

| You can make this change permanent for yourself by appending the line
|         TZ='Europe/Monaco'; export TZ
| to the file '.profile' in your home directory; then log out and log in again.
| 
| Here is that TZ value again, this time on standard output so that you
| can use the /usr/sbin/tzselect command in shell scripts:
| Europe/Monaco

So my question is whether one would really use CEST or the result of
tzseelct.  (Note:  I kept the OP's example of Monaco - I am really
in the U.S.)  And if it is something like CEST, what does one do in
the U.S., where some do not go on Daylight Savings (Summer) Time?

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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 special code to mimic cygwin's tz handling, which may
not be up-to-par.  You'll have to check the source code to be sure, but
I rather doubt (b).

--
Chuck

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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.excoffier@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 standard syntaxes for TZ. One begins with a timezone
>name, the other begins with a colon (:). If you supply a colon, then
>the rest of the string is interpreted in an operating system
>specific manner. GNU interprets it as a pathname. And Cygwin uses
>GNU's time library.

If by "Cygwin" you mean the dll, then it doesn't use GNU's time library
but it does try to match the same behavior.

>Na??vely, I thought you might just lack a colon on the front of the
>pathname. I confirmed time(1) honors the pathname syntax. But
>cygcheck(1) mysteriously interprets all pathnames as GMT + 1 hour:
>
>$ TZ=:/usr/share/zoneinfo/US/Central cygcheck -s | head -3 | tail -1
>Current System Time: Thu Jun 09 18:23:42 2011

cygcheck is a non-Cygwin application.  It is not surprising that it would
not interpret TZ in a way that is consistent with linux.  It really
makes no sense at all to use cygcheck as some sort of method to report
the system time.  Use 'date(1)'.

>$ TZ=:/usr/share/zoneinfo/Europe/Monaco cygcheck -s | head -3 | tail -1
>Current System Time: Thu Jun 09 18:23:49 2011
>$ TZ=:/usr/share/zoneinfo/GMT cygcheck -s | head -3 | tail -1
>Current System Time: Thu Jun 09 18:23:56 2011
>$ TZ=:/usr/share/zoneinfo/Asia/Calcutta cygcheck -s | head -3 | tail -1
>Current System Time: Thu Jun 09 18:23:59 2011
>
>It gets local time right:
>
>$ cygcheck -s | head -3 | tail -1
>Current System Time: Thu Jun 09 12:25:04 2011
>
>And it gets GMT right:
>
>$ TZ=GMT cygcheck -s | head -3 | tail -1
>Current System Time: Thu Jun 09 17:31:32 2011
>
>So cygcheck(1) is honoring TZ, but it trips over a pathname in a
>way that date(1) does not.

And date(1) is what you should be using.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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 have to check the
> source code to be sure, but I rather doubt (b).

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 GNU, and therefore cygcheck(1) has Microsoft C RTL behavior.
Microsoft C RTL does not support the pathname syntax extension;
that's a GNU thing.

http://support.microsoft.com/kb/155293/a

Based on the article above, it seems the MS CRTL returns times that
are off by 1 hour if you set TZ and also have daylight saving time
enabled in the Date/Time control panel. That is almost certainly why
cygcheck(1) is returning GMT +1 hour instead of GMT when you pass it
an invalid TZ.

Cheers,

MetaEd

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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 GNU, and therefore cygcheck(1) has Microsoft C RTL behavior.
> Microsoft C RTL does not support the pathname syntax extension;
> that's a GNU thing.

Exactly. That's why i suggested to use the UTC time zone (rather than
an implicit local one), which msvcrt.dll probably is able to provide
with no bug.

We also could go a little bit beyond cgf's suggestion in
http://cygwin.com/ml/cygwin/2011-06/msg00091.html
(to use `date(1)') and remove completely the
`Current System Time:' line in `cygcheck -s'. Already,
this time indication is not given under the
other cygcheck's options.

Regards.

Denis Excoffier.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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));
>>
>> It's using C RTL calls. And cygcheck(1) is linked with msvcrt.dll,
>> not GNU, and therefore cygcheck(1) has Microsoft C RTL behavior.
>> Microsoft C RTL does not support the pathname syntax extension;
>> that's a GNU thing.
>
>Exactly. That's why i suggested to use the UTC time zone (rather than
>an implicit local one), which msvcrt.dll probably is able to provide
>with no bug.
>
>We also could go a little bit beyond cgf's suggestion in
>http://cygwin.com/ml/cygwin/2011-06/msg00091.html
>(to use `date(1)') and remove completely the `Current System Time:'
>line in `cygcheck -s'.  Already, this time indication is not given
>under the other cygcheck's options.

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.

Just think of all of the other things that "cygcheck -s" is doing in
addition to displaying the date.  cygcheck is most definitely not
intended for this purpose.

cgf


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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 out that having the date there is
useful. I won't try to mind-read the OP's purpose, but I don't suppose
it was simply to display the date, and I do suppose it is better
served now that he knows how to get the date right.

Cheers,

MetaEd

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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 at least in my (legitimate) use of TZ,
- not fully adequate for reference purposes since
   it does not specify the time zone.

It therefore deserves improvement.

But since it seems difficult to make it correct due
to specific constraints (windows program), feel free
not to modify it. Users like me will have to
'export TZ=UTC' before 'cygcheck -s'. Not difficult.

Or change cygcheck's specification for the better: use
UTC date instead, since printing UTC date does not
depend/rely on TZ:
Current System Time (UTC): Thu Jun 09 07:07:14 2011

> Again: you shouldn't use "cygcheck -s" as a method to find the system
> date.
Sorry, next time i'll use 'alias foobar' instead of 'alias cygdate'.


Regards,

Denis Excoffier.




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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 date(1).
>
>Currently the `Current System Time' line is:
>- incorrect at least in my (legitimate) use of TZ,
>- not fully adequate for reference purposes since
>   it does not specify the time zone.
>
>It therefore deserves improvement.
>
>But since it seems difficult to make it correct due to specific
>constraints (windows program), feel free not to modify it.  Users like
>me will have to 'export TZ=UTC' before 'cygcheck -s'.  Not difficult.

When I said the date was useful I was obviously referring to it being
useful in the context for which "cygcheck -s" is used - reporting
configuration info to the cygwin mailing list.  That's why "cygcheck -s"
exists.  In that context, knowing, generally, when the command was run
on the reporter's system is useful.

>Or change cygcheck's specification for the better: use
>UTC date instead, since printing UTC date does not
>depend/rely on TZ:
>Current System Time (UTC): Thu Jun 09 07:07:14 2011
>
>>Again: you shouldn't use "cygcheck -s" as a method to find the system
>>date.
>
>Sorry, next time i'll use 'alias foobar' instead of 'alias cygdate'.

Actually an alias does nothing to illustrate this issue.  Just cutting
and pasting the output from cygcheck -s would have been enough to show
what you're talking about.  Unless you are reporting a problem with
aliases, providing an alias implies that you actually intend to use the
alias for some purpose.

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 patch to cygcheck.cc.  If you don't want
to provide a patch then you could also investigate modifying the
cygcheck output via sed to match what you require.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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 patch to cygcheck.cc.

Wrong by 1h is not pinpoint accuracy (i think). Here is a patch that  
describes what i mean:

--- ./cygwin-snapshot-20110608-1/winsup/utils/cygcheck.cc        
2011-04-07 08:09:28.000000000 +0200
+++ ./cygwin-snapshot-20110608-1.new/winsup/utils/cygcheck.cc    
2011-06-10 19:31:59.000000000 +0200
@@ -1398,7 +1398,9 @@

    printf ("\nCygwin Configuration Diagnostics\n");
    time (&now);
-  printf ("Current System Time: %s\n", ctime (&now));
+  /* UTC is better than local time for reference purposes, and also  
does
+  not depend on TZ, which is problematic in certain cases under  
msvcrt.dll */
+  printf ("Current System Time (UTC): %s\n", asctime (gmtime (&now)));

    OSVERSIONINFOEX osversion;
    osversion.dwOSVersionInfoSize = sizeof (OSVERSIONINFOEX);


Also to be considered similar patches for the other programs that  
don't link
with cygwin1.dll, if necessary.

Hope this helps.

Regards.

Denis Excoffier.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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, but I disagree with your patch. Idiot
proofing cygcheck(1) by forcing GMT on the user is overkill.
cygcheck(1) only gives invalid output when it gets invalid input.
Did cygcheck(1) and date(1) both give valid output with
TZ=CET-1CEST?

Cheers,

MetaEd

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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 pinpoint accuracy (i think).
>
>I realize I don't have a vote, but I disagree with your patch. Idiot
>proofing cygcheck(1) by forcing GMT on the user is overkill.
>cygcheck(1) only gives invalid output when it gets invalid input.
>Did cygcheck(1) and date(1) both give valid output with
>TZ=CET-1CEST?

FWIW, I'm not going to apply the patch.  I may think about accepting a
patch which displays the current timezone along with the current time or
which causes cygcheck to understand Cygwin's TZ usage but there is no
reason to force the date to UTC.  It's supposed to be the "Current
System Time" and that implies that it's the time the user expects when
they look at the clock on their wall.

I'm trying to be accommodating in case there is a valid concern lurking
somewhere here but so far I think this whole discussion is really rather
tempest in a teapot-y.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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 my homegrown format for date I think this works (and 
personally I rather like my invention... :-).

-- 
Lee Maschmeyer
Wayne State University Computing Center
5925 Woodward, #281
Detroit MI 48202
USA 


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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 cannot imagine why you suggested the OP 
use them.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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 correct values for TZ. I 
certainly was not taking issue with the suggestion you made. If it is the 
case that that directory is not known to cygcheck then it seems to me that 
it ought to be. This is the Cygwin location of zoneinfo at any rate, and 
when I tested my value it worked for the `date' program.

-- 
Lee Maschmeyer
Wayne State University Computing Center
5925 Woodward, #281
Detroit MI 48202
USA 


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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. 
The zoneinfo standard recognizes Europe/Monaco. All UNIX systems 
implement the UNIX standard; many implement zoneinfo also. The GNU CRTL 
implements both. The Windows CRTL implements the UNIX standard (actually 
it implements a subset) but does not implement zoneinfo.
> If it is the case that that directory is not known to cygcheck then it 
> seems to me that it ought to be.
You could link cygcheck to the GNU CRTL instead of the Windows CRTL, but 
that defeats cygcheck's purpose.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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 posix/Europe/Monaco. So I set:
>>
>>Apparently you didn't actually read the whole thread here.  You really should.
>
>Apparently I did.

Consider these messages:

http://cygwin.com/ml/cygwin/2011-06/msg00088.html
http://cygwin.com/ml/cygwin/2011-06/msg00091.html
http://cygwin.com/ml/cygwin/2011-06/msg00094.html

They make it clear that cygcheck is a windows program.  So, since
cygcheck doesn't use cygwin1.dll to translate the time zone,
/usr/share/zoneinfo is irrelevant.

If you are trying to gain clarification on how the Cygwin DLL does
timezone translation then please don't hijack this thread for that.
Start a new one.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck's understanding of TZ

[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 are two standards in play. The UNIX standard recognizes CET-1CEST. 
>The zoneinfo standard recognizes Europe/Monaco. All UNIX systems 
>implement the UNIX standard; many implement zoneinfo also. The GNU CRTL 
>implements both. The Windows CRTL implements the UNIX standard (actually 
>it implements a subset) but does not implement zoneinfo.
>> If it is the case that that directory is not known to cygcheck then it 
>> seems to me that it ought to be.
>You could link cygcheck to the GNU CRTL instead of the Windows CRTL, but 
>that defeats cygcheck's purpose.

Ok.  We're now inexplicably looping back to the beginning of the
discussion.  Please consider this thread officially terminated.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple