A couple of new plugins

[Charles Dye]

Two add-ins to do things that I sometimes want to do. Maybe someone else will find them useful.

PopInfo -- Check a file's information while composing a command line. Control-K is nice, but Control-Q is quicker. unm.edu/~cdye/plugins/popinfo.html

Chill -- Schedule a command to run later; SCHTASKS is a little ponderous for one-off jobs. hunm.edu/~cdye/plugins/chill.html

 

[Jay Sage]

Charles,

I just tried to play with your new plugins, but they won't install --
because (I assume) I'm running the 64-bit version of TCMD. Can you
generate 64-bit versions? If I install the 32-bit version of TCMD, would
they then run, even under the 64-bit Windows 7?

-- Jay

 

[Charles Dye]

I just tried to play with your new plugins, but they won't install --
because (I assume) I'm running the 64-bit version of TCMD. Can you
generate 64-bit versions? If I install the 32-bit version of TCMD, would
they then run, even under the 64-bit Windows 7?

Sorry, but I don't have any 64-bit systems to test with. I presume that 32-bit TC would run under 64-bit Windows, but again, I have no way of trying it myself.

 

[dcantor]

PopInfo -- Check a file's information while composing a command line. Control-K is nice, but Control-Q is quicker. unm.edu/~cdye/plugins/popinfo.html

I like it. It would be even more useful if the display of a timestamp could be modified to include the time offset being used for it, something like

Created:                  15-Nov-2009           15:23:52 -0500
Modified:                 29-Apr-2010            11:26:43 -0400
Accessed:                29-Apr-2010            11:26:43 -0400

Perhaps even an option to display the times in UTC.

 

[Charles Dye]

I like it. It would be even more useful if the display of a timestamp could be modified to include the time offset being used for it, something like

I honestly can't think of any better way to do that than to get both localized and UTC times, then subtract....

Perhaps even an option to display the times in UTC.

That wouldn't be difficult, but would it really be useful?

 

[Steve Fabian]

| ---Quote (Originally by dcantor)---
|| I like it. It would be even more useful if the display of a
|| timestamp could be modified to include the time offset being used
|| for it, something like
| ---End Quote---
| I honestly can't think of any better way to do that than to get both
| localized and UTC times, then subtract....
|
| ---Quote---
|| Perhaps even an option to display the times in UTC.
| ---End Quote---
| That wouldn't be difficult, but would it really be useful?

Variable functions @FILEDATE and @FILETIME have the UTC option since V9.
What would be much more useful to me is a way to force all conversions
between the stored UTC and corresponding local time based on the time
difference in effect at the time of the event, so the time a picture of
sunrise was taken would be reported the same no matter when I view it. I
have many files named according to their original timestamp using
4DOS/4NT/TCC batch files. When I try to merge files to a backup device,
using the /U option of TCC's COPY, I may overwrite gigabytes of unmodified
files with themselves due to the virtual timestamp change when one of the
devices is NTFS but not the other.
--
Steve

 

[dcantor]

(offset indication)

I honestly can't think of any better way to do that than to get both localized and UTC times, then subtract....

That's surprising. I had assumed you must have had to figure out what the correct offset from UTC *was* for the selected timestamp in order to get the localized value. But thanks for considering it.

(UTC times)

That wouldn't be difficult, but would it really be useful?

Sometimes. Not often. I can always do

echo %@filetime[file,u]

Again, thanks for considering it.

 

[Charles Dye]

What would be much more useful to me is a way to force all conversions
between the stored UTC and corresponding local time based on the time
difference in effect at the time of the event, so the time a picture of
sunrise was taken would be reported the same no matter when I view it. I
have many files named according to their original timestamp using
4DOS/4NT/TCC batch files. When I try to merge files to a backup device,
using the /U option of TCC's COPY, I may overwrite gigabytes of unmodified
files with themselves due to the virtual timestamp change when one of the
devices is NTFS but not the other.

Something like this, perhaps? unm.edu/~cdye/plugins/iso8601.html#f_filestamp

 

[Charles Dye]

That's surprising. I had assumed you must have had to figure out what the correct offset from UTC *was* for the selected timestamp in order to get the localized value.

No, just checking the underlying filesystem and calling the correct APIs accordingly.

 

[dbartt]

Charles Dye wrote:

> ---Quote (Originally by dcantor)---
> That's surprising. I had assumed you must have had to figure out what the correct offset from UTC *was* for the selected timestamp in order to get the localized value.
> ---End Quote---
> No, just checking the underlying filesystem and calling the correct APIs accordingly.
>

I'm a bit confused about this. AFIK the NTFS file system does not record the DST
UTC offset in effect at the "event" time so how is it possible to reconstruct
the true event time without figuring out what the UST offset was? Would you
share what the "correct" APIs are to do this?

Dennis

 

[Charles Dye]

Charles Dye wrote:

I'm a bit confused about this. AFIK the NTFS file system does not record the DST UTC offset in effect at the "event" time so how is it possible to reconstruct the true event time without figuring out what the UST offset was? Would you share what the "correct" APIs are to do this?

The magic call is SystemTimeToTzSpecificLocalTime(), which converts a UTC time (which is how timestamps are stored in NTFS) to a local time, taking into account the local timezone and whether or not DST was in force at that point in time.

But while this seems to be the right way to handle NTFS timestamps, it's definitely not the right thing for FAT filestamps, which store the local time to begin with.

 

[dcantor]

Something like this, perhaps? unm.edu/~cdye/plugins/iso8601.html#f_filestamp

That will help me! Thank you.

 

[dbartt]

> I'm a bit confused about this. AFIK the NTFS file system does not record the DST UTC offset in effect at the "event" time so how is it possible to reconstruct the true event time without figuring out what the UST offset was? Would you share what the "correct" APIs are to do this?
> ---End Quote---
> The magic call is SystemTimeToTzSpecificLocalTime(), which converts a UTC time (which is how timestamps are stored in NTFS) to a local time, taking into account the local timezone and whether or not DST was in force at that point in time.
>

I'm pretty sure that SystemTimeToTzSpecificLocalTime uses the current DST
setting for the specified zone rather than that of the time being converted.

Quoting from the MS help:

"The SystemTimeToTzSpecificLocalTime function takes into account whether
daylight saving time (DST) is in effect for the local time to which the system
time is to be converted."

No mention of historical DST value.



And this quote:
"The SystemTimeToTzSpecificLocalTime function may calculate the local time
incorrectly under the following conditions:
* The time zone uses a different UTC offset for the old and new years.
* The UTC time to be converted and the calculated local time are in
different years."

This implies an inability to adjust for different event and local time zones,
and no knowledge of historical DST settings.

Dennis

 

[Jim Cook]

>
> I'm pretty sure that SystemTimeToTzSpecificLocalTime uses the current DST
> setting for the specified zone rather than that of the time being
> converted.
>

I used this function in my DIR replacement and it will display the same time
for a file all year round, unlike explorer and the standard CMD/TCC DIR
calls. All those agree with each other but files switch times twice a year.

--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.

 

[Charles Dye]

I'm pretty sure that SystemTimeToTzSpecificLocalTime uses the current DST
setting for the specified zone rather than that of the time being converted.

Quoting from the MS help:

"The SystemTimeToTzSpecificLocalTime function takes into account whether daylight saving time (DST) is in effect for the local time to which the system time is to be converted."

No mention of historical DST value.

You're interpreting that statement the exact opposite of the way I'm reading it. Which means that it isn't very well-written, I suppose; but the function does give the correct answer in my testing.

And this quote:
"The SystemTimeToTzSpecificLocalTime function may calculate the local time
incorrectly under the following conditions:
* The time zone uses a different UTC offset for the old and new years.
* The UTC time to be converted and the calculated local time are in
different years."

As far as I know, the UTC offsets for United States time zones have never been changed. That's probably true of Canada, Mexico, and western Europe as well. I don't know what country prompted that caveat, but it doesn't worry me.

 

[dcantor]

As far as I know, the UTC offsets for United States time zones have never been changed. That's probably true of Canada, Mexico, and western Europe as well. I don't know what country prompted that caveat, but it doesn't worry me.

But the dates at which DST is in effect have changed, individual counties (e.g., in Indiana) have moved from Eastern to Central time (or the reverse), and there have been years when DST was in effect year-round.

I doubt there's any perfect solution to the problem.

I think this plugin helps a great deal.

 

[dbartt]

> I doubt there's any perfect solution to the problem.
>
> I think this plugin helps a great deal.
>

Agreed. I was only trying to clarify that while the plugin can return a
consistent, non-changing event time, it cannot return the original, local event
time without knowing both the original time zone and DST setting. The plugin
provides a time stamp that doesn't change twice a year which is a great improvement.

 

[dbartt]

And this quote:

> "The SystemTimeToTzSpecificLocalTime function may calculate the local time
> incorrectly under the following conditions:
> * The time zone uses a different UTC offset for the old and new years.
> * The UTC time to be converted and the calculated local time are in
> different years."
> ---End Quote---
> As far as I know, the UTC offsets for United States time zones have never been changed. That's probably true of Canada, Mexico, and western Europe as well. I don't know what country prompted that caveat, but it doesn't worry me.
>

But computers can change time zones. If I'm traveling and choose to reset my
computer's time zone to local time then all my NTFS file times will shift.

 

[Charles Dye]

But computers can change time zones. If I'm traveling and choose to reset my computer's time zone to local time then all my NTFS file times will shift.

Yes, indeed they will, no matter which APIs you use. And FAT filestamps won't. Isn't Windows a constant source of wonder and delight?