clock format ... -timezone cest - bug, misusage, ...



Hi,

I just got stuck within a problem of using the clock command.

I used "file mtime" to retrieve the modification date/time of a file,
which I see (in the explorer) to be e.g. "14.2.2003 at 0:00:00".

My usage of the clock command in tcl 8.5.0 is:

% set mtime [file mtime $dummy]
1045173600
% clock format $mtime
Thu Feb 13 23:00:00 CET 2003
% clock format [clock scan now]
Mon Mar 31 17:04:44 CEST 2008
% clock format $mtime -timezone cest
time zone cest not found

Why the mtime returns CET as timezone, while "now" returns CEST?
And - why "-timezone" does not accept "cest" as timezone, even if the
man page tells this string to be valid?

Ok - 13th February of 2003 was in "wintertime" (CET), while "now" is
in the "summertime" and so "CEST"?
Is it simply because of this "wintertime", "summertime" thing?

Hhhm - perhabs I should write about the original problem ...

The mtime of the used file is set by the download manager GetRight to
reflect the original mtime of the file downloaded from the server.
And I'm a bit irritated, because the tcllib ftp package returns a
mtime, which is 23hours, 28minutes and 26seconds younger, than
GetRight sets the local file mtime to:

% set mtime [file mtime $dummy]
1045173600
% clock format $mtime
Thu Feb 13 23:00:00 CET 2003
% set remoteMtime [ftp::ModTime $handle $dummy]
1045258106
% clock format $remoteMtime
Fri Feb 14 22:28:26 CET 2003

So - who failed? GetRight or the tcllib ftp package?

The web browser tells me "14.02.2003 00:00:00"!

So, the explorer tells me the righttime, which is set by GetRight. And
using tcl's "file mtime" + 1h (perhabs for "summertime") would be ok,
while the tcllib ftp package failed, right?

Or is it about timezon conversions, because of asking a server
somewhere in the internet in a different timezone for a mtime of a
provided file (timezone ???) and comparing it with the mtime of a
local stored file (timezone CEST)?

So - what do I have to think of, handling such mtimes, perhabs from
different timezones? (oh - it shouldn't ... the ftp server is from the
Netherlands, while I request files from Germany)

May someone can help?

Thanks in advance!

Best regards,

Martin Lemburg
.



Relevant Pages

  • Re: how to realize a kind of TCL-daemon?
    ... Martin Mertens wrote: ... set prev_time [clock seconds] ... set mtime ...
    (comp.lang.tcl)
  • Re: how to realize a kind of TCL-daemon?
    ... set prev_time [clock seconds] ... set mtime ... Although I see the problem that this solution is not even-driven, so two fast file changes of services.tcl would eventually not be recognized and only lead to the execution of the later version of services.tcl. ...
    (comp.lang.tcl)
  • Re: [head tinderbox] failure on amd64/amd64
    ... Wed Aug 20 10:09:11 CEST 2008 ... the file's mtime is between N-1 and N days. ... the test will fail if sys/sys/param.h's mtime is between now ...
    (freebsd-current)
  • Re: [head tinderbox] failure on amd64/amd64
    ... Wed Aug 20 10:09:11 CEST 2008 ... the file's mtime is between N-1 and N days. ... the test will fail if sys/sys/param.h's mtime is between now ...
    (freebsd-current)
  • Re: [9fans] Re: Linux 9p timestamps
    ... Timezone tables being trash at one end or the other? ... How about 10 lines of C to print stat's mtime of the ... shared file in decimal from both plan9's point of view ...
    (comp.os.plan9)