Re: cygcheck's understanding of TZ
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
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
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
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
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
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
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
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
Re: cygcheck's understanding of TZ
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
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
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
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
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
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.0 +0200 +++ ./cygwin-snapshot-20110608-1.new/winsup/utils/cygcheck.cc 2011-06-10 19:31:59.0 +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
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
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 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
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. uAm 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
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
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 /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
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
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
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
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
