clock and summer-time
Gerry
I have a problem with the clock statement. Here in the Netherlands we
are 1 hour ahead of GMT and have daylight saving time (summer-time).
Saturday we went over from winter-time to summer-time (+1 hour). TCL
has decided that summer-time means 1 hour *back*. The only way of
influencing this is by the –gmt parameter, but this just creates a –2
hour difference. The format I use is: clock format [clock seconds]
-format {%X}.
Has anyone else had this problem?
Thanks in advance,
Gerry.
Arjen Markus
>
> Hi,
>
> I have a problem with the clock statement. Here in the Netherlands we
> are 1 hour ahead of GMT and have daylight saving time (summer-time).
> Saturday we went over from winter-time to summer-time (+1 hour). TCL
> has decided that summer-time means 1 hour *back*. The only way of
> hour difference. The format I use is: clock format [clock seconds]
> -format {%X}.
> Has anyone else had this problem?
>
> Thanks in advance,
> Gerry.
It is quite correct in this:
Your time (say 15:20 today) is actually 14:20 MET "winter-time" and
as GMT is not influenced by DST, 13:20 GMT.
Hence, the classical mistake, a 2-hour difference.
Regards,
A(nother Dutchman)rjen
Gerry
Thanks for the reply BUT
1. On Friday morning the time was correct i.e. same as my system clock
(Tcl 09:00, System clock 09:00)
2. Sunday morning (very early) all the clocks went forward 1 hour
(summer-time)
3. Monday morning my system clock said 09:00 which was 1 hour advanced
(correct) but TCL said 08:00.
4. I set my system clock back to 29/3 without changing the time. Tcl
then said it was 09:00
5. Back to 31/3
Tcl said it was again 08:00
If Tcl doesn't recognise summer-time then why the difference between
the two dates.
If Tcl does recognise summer-time then what the f*** is going on? It
went BACK one hour. The gmt thingie I understand but i don't use gmt.
BTW this is on a Windows machine not unix. Is there a environment
setting I need, and if so where do I put it - and no wise cracks :-)
Thanks,
Gerry.
Benjamin Riefenstahl
Gerry <ger...@xs4all.nl> writes:
> BTW this is on a Windows machine not unix. Is there a environment
> setting I need, and if so where do I put it - and no wise cracks :-)
I had this problem too. I have a "TZ" environment variable which
takes precendence over the system time zone settings and that was the
problem.
What are the results of
clock format [clock seconds]
and
set env(TZ)
on your system?
so long, benny
Gerry
Thanks for the reply.
The set env doesn't seem to work for me. I am using WISH83 and windows
NT 4 sp6 if that makes a difference.
Thanks for your help,
Gerry.
> clock format [clock seconds]
Tue Apr 01 07:34:26 MET 2003 (should be 08:34:26)
> set env(TZ)
can't set "env": variable is array
Ralf Fassel
| > set env(TZ)
| can't set "env": variable is array
Try
array get env TZ
IIRC, on windows there is a conflict with the system hardware clock
and the Unix approach of setting the TZ variable. Windows adjusts the
hardware clock to cope with DST, whereas Unix leaves the hardware
clock alone, and uses the TZ variable to tell the time-handling C
library calls how to deal with DST.
However, as you describe it, I would have expected the time difference
in the other way (+1 hour instead of -1 hour).
R'
(getenv "TZ") "MET-1MDT-2,M3.5.0/2:00,M10.5.0/3:00"
Dan Smart
news:cda46c45.03033...@posting.google.com:
> Hi Benjamin,
>
> Thanks for the reply.
> The set env doesn't seem to work for me. I am using WISH83 and windows
> NT 4 sp6 if that makes a difference.
>
> Thanks for your help,
> Gerry.
>
>> set env(TZ)
> can't set "env": variable is array
This error implies that you did not type the command as given...
It should be 's' 'e' 't' 'space' 'e' 'n' 'v' '(' 'T' 'Z' ')'
It contains exactly one space, an open paren, and a close paren.
You will probably get the error <can't read "env(TZ)": no such variable>
which will indicate that this isn't the source of your problems, but this
is important diagnostic information.
HTH
Dan
--
Dan Smart. C++ Programming and Mentoring.
cpp...@dansmart.com
ADDvantaged
Kevin Kenny
> The set env doesn't seem to work for me. I am using WISH83 and windows
> NT 4 sp6 if that makes a difference.
Are your running one of the binary distributions, or did you
rebuild from source? If you are running a binary distibution, where
did you get it? If not, what compiler and options did you use?
The reason I ask is that Microsoft has had literally hundreds of
bugs regarding the clock chages in Spring and Autumn. This one sounds
suspiciously like
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B214661
which, if I recall correctly, requires both building with VC++ SP3
or higher and installing a new MSVCRT.DLL on the client machine.
This has been a tremendous cause of frustration for me. In at least
one control application that I've hosted on Windows, we have to go
around and set all the clocks to Greenwich in advance of time
changes and back to local afterward - because some versions of the
operating system even get UTC wrong during the transition.
--
73 de ke9tv/2, Kevin
Benjamin Riefenstahl
ger...@xs4all.nl (Gerry) writes:
> > clock format [clock seconds]
> Tue Apr 01 07:34:26 MET 2003 (should be 08:34:26)
That means that Tcl doesn't get the system settings, because the NT
system time zone names are more verbose, e.g. my German system says
"Westeuropäische Sommerzeit" instead of your "MET" above, when I do
not set TZ. So that time zone specification indicates that you
actually have a TZ environment variable set (or, less likely, some
other interference).
> > set env(TZ)
> can't set "env": variable is array
That is not an error that can result from that command. Are you sure
you have not entered
set env (TZ)
or something similar? Spaces are very significant in Tcl.
If you actually have a TZ variable set, you can do several things, all
of which have pros and cons:
- Remove the variable from your system altogether (see your
environment settings in "My Computer" -> "Environment"). Now that
variable is probably there for a reason, something that you have
installed has put it there, so removing it may not be a good idea.
- Set the variable to a (more) correct value. I use MET-2DST at the
moment. Doing to that way means you will have to change it
everytime the clock is changed. Sadly, I doubt that the MS C
runtime (which is responsible here, I think) accepts a full POSIX
spec, which would be highly cryptic, but would work without having
to change it twice a year. You may want to check MSDN or the MS
Knowlegde Base to see if they have a solution along those lines.
- Remove the variable from inside your Tcl programs by adding "unset
env(TZ)" at the start of every program. That would have to be done
for every Tcl program though, even those you download, so it may not
be a good solution either.
Hope this helps, benny
Gerry
I am a real newbie (2 days now) when it comes to tcl and have just
inherited this app. As yet I don't know anything about binary
distributions; the app is run with the wish83 interpreter. I was
really hoping for a quick "Ah yes, that's because you ...." kind of
answer before delving into the books, but it seems to be more
complicated than I at first thought.
I will have another go at investigating the TZ variable at work
tomorrow, but I am sure I don't have one anywhere.
I think I will have to delve deeper into TCL before I ask any more
questions as I am not sure I really understand all the answers.
Especially about wat has to be compiled and built. I will get back to
you on this.
Thanks again,
Gerry.
Ulrich Schoebel
>
> - Set the variable to a (more) correct value. I use MET-2DST at the
> moment. Doing to that way means you will have to change it
> everytime the clock is changed. Sadly, I doubt that the MS C
> runtime (which is responsible here, I think) accepts a full POSIX
> spec, which would be highly cryptic, but would work without having
^^^^^^^^^^^^^^ not really
> to change it twice a year.
Hi Benny,
The TZ format is not too complicated. From the man page:
std offset dst [offset],start[/time],end[/time]
Taking defaults into account TZ for Germany is
TZ=MEZ-1MSZ,M3.5.0,M9.5.0
which means: My standard time zone is MEZ, which is 1 hour ahead of GMT,
my daylight saving zone is MSZ, which is 1 hour (default) ahead of my
standard time zone, it switches to DST on sunday (0) of the last week
(5)
of march (3) at 2:00 AM (default), and switches back on sunday (0) of
the
last week (5) of september (9) at 2:00 AM (default).
The full TZ string would be TZ=MEZ-1MSZ-2,M3.5.0/2:00:00,M9.5.0/2:00:00
Best regards
Ulrich
--
SIGOS Systemintegration GmbH
- TESTING IS OUR COMPETENCE -
Fon +49 911 95168-0
www.sigos.de
Benjamin Riefenstahl
> Benjamin Riefenstahl wrote:
> > [...] Sadly, I doubt that the MS C runtime (which is
> > responsible here, I think) accepts a full POSIX spec, which
> > would be highly cryptic, but would work without having
^^^^^^^^^^^^^^ not really
> > to change it twice a year.
>
Ulrich Schoebel <ulrich....@sigos.de> writes:
> The TZ format is not too complicated. From the man page:
>
> std offset dst [offset],start[/time],end[/time]
>
> Taking defaults into account TZ for Germany is
>
> TZ=MEZ-1MSZ,M3.5.0,M9.5.0
I understand that when you spell it out in slow motion, and I could
even study the man page myself, but I personally still think it looks
pretty cryptic. I certainly *have* to look at the man page to even
understand the date format. To each his own.
Anyway the main question here is, does the MS run-time support this?
> which means: My standard time zone is MEZ, which is 1 hour ahead of
> GMT, my daylight saving zone is MSZ, which is 1 hour (default) ahead
> of my standard time zone, it switches to DST on sunday (0) of the
> last week (5) of march (3) at 2:00 AM (default), and switches back
> on sunday (0) of the last week (5) of september (9) at 2:00 AM
> (default).
> The full TZ string would be TZ=MEZ-1MSZ-2,M3.5.0/2:00:00,M9.5.0/2:00:00
Actually, summertime ends in October in the EU, according to my
sources. Someone from Redhat once posted this spec on a mailing list:
TZ=CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00
Can you comment on the differences of the names?
so long, benny
Duane Bozarth
Benjamin Riefenstahl wrote:
>
> Hi Ulrich,
>
> > Benjamin Riefenstahl wrote:
>
> > > [...] Sadly, I doubt that the MS C runtime (which is
> > > responsible here, I think) accepts a full POSIX spec, which
> > > would be highly cryptic, but would work without having
> ^^^^^^^^^^^^^^ not really
> > > to change it twice a year.
> >
> Ulrich Schoebel <ulrich....@sigos.de> writes:
>
> > The TZ format is not too complicated. From the man page:
> >
> > std offset dst [offset],start[/time],end[/time]
> >
> > Taking defaults into account TZ for Germany is
> >
> > TZ=MEZ-1MSZ,M3.5.0,M9.5.0
>
> I understand that when you spell it out in slow motion, and I could
> even study the man page myself, but I personally still think it looks
> pretty cryptic. I certainly *have* to look at the man page to even
> understand the date format. To each his own.
>
> Anyway the main question here is, does the MS run-time support this?
>
AFAIK, yes the MS rtl's do at least pay attention to TZ. Whether any
particular rev level is error-free is another issue (and I don't really
know).
Michael Haschek
Hi all,
we have the same prob here in Munich, but only on W2k-machines.
Our "set env(TZ)" delivers "MEZ-1MESZ-2".
It seems, that TCL is not understanding this variation of the TZ-Info.
Is there a hint from the TCL-Gurus ? But this should not lead to a recompilation.
Best
Michael
Gerry
Just one question if I may? set env(TZ) gives MET-1MEST (yes it was
the space).
Does this mean that I am at MET -1? If this is true then MET should
give me the correct time! Can I set this variable in my prog. and if
so how?
Thanks,
Gerry.
Ulrich Schoebel
>
> Anyway the main question here is, does the MS run-time support this?
>
Don't know. I avoid MS whenever possible (almost always).
>
> Actually, summertime ends in October in the EU, according to my
> sources. Someone from Redhat once posted this spec on a mailing list:
>
> TZ=CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00
>
Yes, that's correct. I believe I remember summertime ended in september
a few years ago.
> Can you comment on the differences of the names?
>
AFAIK, CET and CEST are the correct abbreviations. Nevertheless I've
seen MEZ and MESZ/MSZ very often on systems used in Germany.
> so long, benny
Benjamin Riefenstahl
ger...@xs4all.nl (Gerry) writes:
> Just one question if I may? set env(TZ) gives MET-1MEST (yes it was
> the space).
> Does this mean that I am at MET -1? If this is true then MET should
> give me the correct time!
No, TZ=MET-1MEST says that you (the user or programmer) want programs
to assume that the current timezone is one hour from GMT, at least
that is what the VC runtime makes of that. With summertime we are
actually -2 currently. As the VC runtime seems to just look at the
number that comes after the first three characters (I just tried), we
need MST-2 or CST-2 or some variation of that.
> Can I set this variable in my prog. and if so how?
set ::env(TZ) "CST-2"
Or, if you can rely on the OS settings instead
catch {unset ::env(TZ)}
so long, benny
Benjamin Riefenstahl
Duane Bozarth <dp_bo...@swko.dot.net> writes:
> AFAIK, yes the MS rtl's do at least pay attention to TZ.
If you want to call it "paying attention". The runtime just looks at
the number that comes after the first three characters. I just tried
it out.
Even the docs on MSDN talk about "three-letter" codes and they also
say that you can only add a three-letter code to get
daylight-saving-time. Then it goes on: "The C run-time library
assumes the United States's rules for implementing the calculation of
Daylight Saving Time (DST)."
I think that's all that can be said about this.
> Whether any particular rev level is error-free is another issue (and
> I don't really know).
The VC runtime never claimed to be a POSIX system, so MS will probably
say that is like it is by design.
so long, benny
Gerry
I now have enough info to try and solve this issue.
Again, thanks to you all,
Gerry.
On 02 Apr 2003 18:12:42 +0200, Benjamin Riefenstahl
Duane Bozarth
look it up. And, of course, your comment regarding MS and standards is
appropriate--the "standard" for MS is whatever the behavior happens to
be in the particular version you have... :(