DST and @AGEDATE?

May 20, 2008
12,175
133
Syracuse, NY, USA
Another thread got me fooling around. I wondered what the local time of day was exactly 183 days ago; to be more precise, exactly 183*10000000*60*60*24 FILETIME (age) units ago. I figured it'd be an hour earlier since DST wasn't in effect then. @AGEDATE doesn't say so.
Code:
v:\> do i=0 to 1 ( echo %@agedate[%@eval[%@makeage[%_date,%_time] - %i*10000000*60*60*24*183]] )
2016-08-10,23:01:50.000
2016-02-09,23:01:50.000
So I wrote my own @AGETOTIME, which does say so.
Code:
v:\> do i=0 to 1 ( echo %@agetotime[%@eval[%_agenow - %i*10000000*60*60*24*183]] )
2016-08-10,23:03:34
2016-02-09,22:03:34
I'm not complaining. But I am very curious about the difference because both @AGEDATE and @AGETOTIME call SystemTimeToTzSpecificLocalTime() and. as far as I can tell, you can't prevent that function from taking DST into account.

So, here I am, very curious.
 
May 29, 2008
572
4
Groton, CT
@agetotime sounds like exactly what I've been looking for. May we look forward to seeing that in some plugin package in the near future?
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
4,689
106
Albuquerque, NM
prospero.unm.edu
I'm not complaining. But I am very curious about the difference because both @AGEDATE and @AGETOTIME call SystemTimeToTzSpecificLocalTime() and. as far as I can tell, you can't prevent that function from taking DST into account.

Does it? I thought @AGEDATE was basically just a wrapper around FileTimeToSystemTime().
 
May 20, 2008
12,175
133
Syracuse, NY, USA
@agetotime sounds like exactly what I've been looking for. May we look forward to seeing that in some plugin package in the near future?
Well, it's in **my** 4UTILS. I also made a change to _AGENOW. Previously, _AGENOW was adjusted for time zone and now it's not. My new thinking is that FILETIMES are absolute/universal ... in the following sense. If I'm on the phone with a friend in another time zone and we both, simultaneously create a file, then his file and my file will have exactly the same FILETIME.

But now my _AGENOW disagrees with @MAKEAGE[%_DATE,%_TIME]. So I have to think about sticking with my changes before I post a new one.
 
May 20, 2008
12,175
133
Syracuse, NY, USA
Yes. I saw it with a debugger. SYSTEMTIMES are UTC, probably not what the user wants to see.
It looks like I was mistaken about that. My test was @MAKEAGE[%_AGENOW] and it was _AGENOW that was calling SystemTimeToTzSpecificLocalTime(). Currently, I'm not doing that any more. I don't know if I'll stick with that change. See my recent reply to Dave C.
 
May 29, 2008
572
4
Groton, CT
I looked through my .BAT and .BTM files and I found I have only instance of using %_AGENOW:
Code:
if exist "%markfile" if %@left[-7,%@eval[%_agenow - 0%@fileage["%markfile"]]] lt 300 quit

This is intended to exit if the same batch file is run less than 5 minutes after it was most recently run before.

Looks like that's the only change I'd have to make if you change the meaning of _AGENOW.
 
May 20, 2008
12,175
133
Syracuse, NY, USA
Looks like that's the only change I'd have to make if you change the meaning of _AGENOW.
That's not the issue. The function I mentioned (@AGETOTIME[], now @FTDATE[]) relies on having a real FILETIME, not an AGE. So it won't work correctly if you give it a @FILEAGE[]. I'm still trying to figure out what to do (if anything). I could leave it all up to the user; he can always turn an AGE into a FILETIME by adding 10000000*60*%_tzo.
 
May 29, 2008
572
4
Groton, CT
Y
That's not the issue. The function I mentioned (@AGETOTIME[], now @FTDATE[]) relies on having a real FILETIME, not an AGE. So it won't work correctly if you give it a @FILEAGE[]. I'm still trying to figure out what to do (if anything). I could leave it all up to the user; he can always turn an AGE into a FILETIME by adding 10000000*60*%_tzo.
Yes, I have half a dozen places where I have that 10000000*60*%_TZO already.
 
May 20, 2008
12,175
133
Syracuse, NY, USA
I'm tired of beating my head against this one. I uploaded a new 4UTILS. _AGENOW is back to giving an AGE. The new function is now called @AGEDATEF[]. It expects a real FILETIME and does this:

FileTimeToSystemTime, SystemTimeToTzSpecificLocalTime, returns "date_string,time_string" according to the default formats.

I hope you can get it to do what you want.

You know, I'm not even sure about the relationship between AGEs and FILETIMEs. If the difference is 10000000*60*%_TZO, then that difference changes with DST, making an AGE a rather tenuous thing.
 
May 29, 2008
572
4
Groton, CT
Thanks, Vince. I *will* get it to do what I need. For me, it's precisely the fact that the difference changes with DST that I'm relying on.

So @AGEDATEF takes an AGE as an argument. It's output differs from the output of @AGEDATE by %_TZO minutes.
That exactly fits my need (or desire, if you prefer), and I can eliminate the messy coding where I was using adding the offset to the result of @AGEDATE.

Thanks, as always, for listening, and for providing the plugins.
 
Last edited: