DST and @AGEDATE?

[vefatica]

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.

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.

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.

 

[dcantor]

@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]

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().

 

[vefatica]

Does it? I thought @AGEDATE was basically just a wrapper around FileTimeToSystemTime().

Yes. I saw it with a debugger. SYSTEMTIMES are UTC, probably not what the user wants to see.

 

[vefatica]

@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.

 

[vefatica]

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.

 

[rconn]

@AGEDATE calls FileTimeToSystemTime, not SystemTimeToTzSpecificLocalTime.

 

[vefatica]

@AGEDATE calls FileTimeToSystemTime, not SystemTimeToTzSpecificLocalTime.

Yeah. That was my mistake.

 

[dcantor]

I looked through my .BAT and .BTM files and I found I have only instance of using %_AGENOW:

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.

 

[vefatica]

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.

 

[dcantor]

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.

 

[vefatica]

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.

 

[dcantor]

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.