DST and @AGEDATE?

#1
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
533
3
Groton, CT
#2
@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?
 
#5
@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.
 
#6
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
533
3
Groton, CT
#9
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.
 
#10
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
533
3
Groton, CT
#11
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.
 
#12
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
533
3
Groton, CT
#13
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: