Home > Archive > Tcl > December 2006 > Re: fooled by shifting date
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: fooled by shifting date
|
|
| Alexandre Ferrieux 2006-12-11, 7:19 pm |
|
On Dec 7, 8:04 am, "slebet...@yahoo.com" <slebet...@gmail.com> wrote:
> I guess you can just copy the code in [clock clicks] since it's
> supported on all supported platforms.. including Windows.
The bad news is that on most systems (except, by chance, unices without
a gettod), including windows, it is implemented based on an
gettod-alike...
So, it looks like times() is ready for the job. Except I don't know the
Windows, shift-safe equivalent.
-Alex
| |
| Alexandre Ferrieux 2006-12-14, 4:17 am |
|
Alan Anderson a =E9crit :
> I'm struggling right now with that issue. As best as I can tell,
> Windows applies the local-to-UTC conversion to all values based on what
> time it is *right now*, whereas Tcl applies it based on what it is for
> the actual time being converted. It makes synchronizing files based on
> UTC modification time somewhat harder than it ought to be.
That's a bit surprising to me. On my Windows XP PC with ActiveStateTcl
8=2E4.13.0, in my local timezone where DST last hit for winter at 2
o'clock in the morning of October 29th, I have:
expr {[clock scan 20061029\ 020000]-[clock scan 20061029\ 015959]}
--> 3601
If you reverse the point of view, since the clock "walks back" by one
hour for winter DST, you lose the injectivity of [clock format] for one
full hour. Hence for example
[clock format 1162081800] --> Sun Oct 29 02:30:00 Romance Daylight
Time 2006
[clock format 1162085400] --> Sun Oct 29 02:30:00 Romance Standard
Time 2006
As you see, the full formatted string preserves injectivity by the word
'Standard/Daylight' in the timezone part, but for most system uses
where you have only %Y%m%d and %H%M%S, the illusion is complete.
Now, file modification times are stored in unix and windows as counts
of seconds since the epoch, that is, [clock seconds], not [clock
format]ted strings. In the light of this, can you revisit your "stamps
going backwards" issue ? For example, if you artificially set back your
clock before the winter DST switch, touch file a just before, touch
file b just after, and look at the integers returned by [file mtime].
What is the delta ? My bet: a few seconds, like always.
-Alex
| |
| Fredderic 2006-12-16, 10:07 pm |
| On Thu, 14 Dec 2006 19:59:11 GMT,=20
Darren New <dnew@san.rr.com> wrote:
> Alexandre Ferrieux wrote:
> Not on FAT systems. FAT stores it as basically packed BCD,
> YYMMDDHHMMSS or some such. I forget the exact details, but there's no
> epoch involved there.
=46rom memory (it's been a long time since I did anything in DOS), that's
not entirely true... I think the year is based from 19-something...
Fredderic
|
|
|
|
|