It's kind of so close and yet so far, Charles. The @Days function is wonderful, but it (or something closely similar or possibly a new parameter on the existing @Days function so as not to "break" existing code) could be made even more wonderful by having a way to also have fractions of a day, something like 2.33333333 days, for approximately 8 hours. Now I really don't have a strong notion of how many decimal places to carry the calculations to other than to say that 7 decimal places of precision are probably enough, particularly given the documented 100 ns resolution of NTFS date/time stamps, which, strictly speaking, require only about that level of precision). Alternatively, functions to subtract times could be added, although I'm not sure they would really be necessary if @Days was altered to return fractional days.
The ISO plugin is wonderful, but it lacks a little something...
- Thread starter mathewsdw
- Start date
Charles Dye
Super Moderator
- May
- 5,328
- 161
Staff member
I assume you want to specify times as well as dates. I image that as being another function altogether, maybe even two or three functions. I'll have to think about it....
Charles, I wrote my own which seem to be working OK. However, that doesn't mean that you couldn't add it to the ISO plugin because I find it kind of hard to believe that I'm the only person in the world who has wanted more general date/time arithmetic capabilities to this point. If you are interested in my routine(s) (mostly nested functions) just say so and I would be glad to zip up and make an attachment from what I've got. (What I've got is not the whole set of what might be needed; specifically it only works with the ages of actual files at the present time, and since that's what I needed in the short term I haven't decided whether I will make them more general than that since I'm otherwise so overloaded that I just don't have that much time to do things I'd just like to do vs. things that I really need to do.)
Charles, I thought I'd add a little bit more to what I did to solve the problem because it might be applicable to you and fairly easy to implement in a compiled language. Specifically, I created a function to convert a time to a fraction of a day (12:00 PM is .5) and another function that converted a fractional day to a time (.5 is changed to 12:00 PM), and doing this makes general date/time arithmetic fairly trivial possibly other than doing some kinds of "fancy" formatting (i.e., output -12 hours rather than -1 day plus 12 hours) when creating the output as an actual time (difference) rather than just a fraction of a day.
Charles Dye
Super Moderator
- May
- 5,328
- 161
Staff member
I'm attaching a beta build of the ISO8601 plugin to this message. Please beat hard on the new functions. I haven't done much testing, and they may be horribly buggy!
- Jan
- 617
- 15
A little off topic, but just downloaded the plugin and was viewing the HTML docs. I must say that I REALLY LIKE your choice of fonts and the layout of your documentation.
Charles Dye
Super Moderator
- May
- 5,328
- 161
Staff member
Thanks!
Charles, thank you for being so quick about it!!!:) And I apologize for my very possibly evident (and often previously mentioned) stupidity. But from what I see, days and time are handled completely separately, meaning that the user has to do a little bit more work (not all that difficult, admittedly, since I've already effectively done the same thing) to subtract two dates and time pairs and return the results in days and fractions of a day. As somebody on this thread suggested (bad memory as to exactly who) adding another completely optional parameter to the @Days function to indicated results should be returned in days and fractions of a day (days and actual time difference would be even better, but I really don't know whether you can return a date/time pair from a function). I know, I know, beggars can't be choosers!;) But thank you yet again at any rate.
- Dan
- Dan
Charles Dye
Super Moderator
- May
- 5,328
- 161
Staff member
Actually, @TIMEDIFF and @TIMEPLUS do accept date-time pairs. Perhaps that's not clear from the (hasty) documentation.
In these two functions, you can specify a date-time pair by sticking them together with an @ sign: 1985-06-01@17:30 would be 5:30 PM on the first of June, 1985. And the date can be in any format recognized by the plugin: T+2@08:00 would be 8 AM the day after tomorrow.
I'm open to suggestions about how the new functions could handle things better -- especially the handling of negatives, the reporting of day offsets in results when no date was specified in the input times, and other such dubious design choices. But I really don't want to muck up @DAYS; it's doing what I intended, subtracting (integer) julians, and I don't want to change its focus.
In these two functions, you can specify a date-time pair by sticking them together with an @ sign: 1985-06-01@17:30 would be 5:30 PM on the first of June, 1985. And the date can be in any format recognized by the plugin: T+2@08:00 would be 8 AM the day after tomorrow.
I'm open to suggestions about how the new functions could handle things better -- especially the handling of negatives, the reporting of day offsets in results when no date was specified in the input times, and other such dubious design choices. But I really don't want to muck up @DAYS; it's doing what I intended, subtracting (integer) julians, and I don't want to change its focus.
Charles, I'm sorry, it was just a matter related to my oft-mentioned stupidity due to my bad memory and partial blindness, and the fact that you didn't do quite the way I had expected you to do it (my mistake!). For a third time, thank you very much!!! This product and the people like you who support it are, simply put, truly wonderful! - Dan
Charles Dye
Super Moderator
- May
- 5,328
- 161
Staff member
Here is a minor update, which makes some small adjustments to time output and documents the expanded date range.
- May
- 608
- 4
All that new stuff looks good, Charles. I especially appreciate your decision not to alter the semantics of @DAYS. Would you allow date-times to have the time portion delimited by a 'T' as well as a '@' for input (and maybe for output)? Using a 'T' would make them ISO compliant, n'est'ce pas? E.g., 2012-06-08T22:13:00 .
Charles Dye
Super Moderator
- May
- 5,328
- 161
Staff member
Okay, try this one....
- May
- 608
- 4
Very fast! Thanks.
- May
- 608
- 4
Charles,
It would be convenient if your time and date functions accepted input in the format
<date>,<time> (with a literal comma), since that is the output of the @AGEDATE function.
What I tried doing was this:
Maybe all that's needed is to allow a comma as well as @ and T as input to @TIMEPLUS.
This _does_ work:
@TIMEPLUS makes a neat-o time-and-date conversion function when specified with an offset of zero.
It would be convenient if your time and date functions accepted input in the format
<date>,<time> (with a literal comma), since that is the output of the @AGEDATE function.
What I tried doing was this:
Code:
echo %@timeplus[%@agedate[0],0,0,0]
ISO8601 plugin: Invalid time "1601-01-01"Maybe all that's needed is to allow a comma as well as @ and T as input to @TIMEPLUS.
This _does_ work:
Code:
echo %@timeplus[%@replace[^c,@,%@agedate[0]],0,0]
01-01-01@0:00:00@TIMEPLUS makes a neat-o time-and-date conversion function when specified with an offset of zero.
Charles Dye
Super Moderator
- May
- 5,328
- 161
Staff member
I looked at it, but that gets ugly. Comma is not only the argument separator, but also a valid decimal separator; you can specify fractional seconds, down to the millisecond. What I'm going to do instead is add an option to @AGEDATE and @FILESTAMP to return T as the date-time separator -- as per ISO 8601 :)
Just for that, I'm making the offset to @TIMEPLUS optional. If you don't specify an offset, it defaults to zero.
(Later: I don't seem to be able to attach a copy as before. "A server error occurred. Please try again later.")
(Later still: Here it is.)
- May
- 608
- 4
That will help, thanks.
What a guy! Ask for an inch and you get a yard. Hint at an inch, and you get a mile!
Thanks, Charles.
- May
- 3,515
- 5
Minor help nits - @agedate:
1/ AGE need not be an NTFS file age, it can be the "age" of any event
2/ AFAIK the resolution is 100ns, not 10ns: change "the number of 10-ns units" to "the number of 100-ns time intervals"
@filestamp: you may want to add that unlike @filedate and @filetime used together, this is a single operation, so inconsistency is impossible (as could happen if you check a log file's age at almost midnight, and an event is logged precisely at midnight). You may also want to make a separate group of the ACW options from the BLU options, and indicate explicitly whether or not their order is significant. In TCC the U requires explicit selection from ACW; what can your program accept?
Would combining the T/@ format option with the "fmt" date format option make sense?
1/ AGE need not be an NTFS file age, it can be the "age" of any event
2/ AFAIK the resolution is 100ns, not 10ns: change "the number of 10-ns units" to "the number of 100-ns time intervals"
@filestamp: you may want to add that unlike @filedate and @filetime used together, this is a single operation, so inconsistency is impossible (as could happen if you check a log file's age at almost midnight, and an event is logged precisely at midnight). You may also want to make a separate group of the ACW options from the BLU options, and indicate explicitly whether or not their order is significant. In TCC the U requires explicit selection from ACW; what can your program accept?
Would combining the T/@ format option with the "fmt" date format option make sense?
- May
- 3,515
- 5
BTW, I love the plugin and use @filestamp exclusively with PDIR (no d or t fields for me).
Charles Dye
Super Moderator
- May
- 5,328
- 161
Staff member
You're right -- a tenth of a microsecond is 100ns, not 10ns. ("Math is hard!" says Barbie.)
The order of A/C/W vs. B/L/U is not important. However, if you have incompatible options -- W with A, or B with L -- then the first one wins.
I don't see why. The date format is shared with a lot of other functions, most of which have nothing to do with time.
- May
- 3,515
- 5
I would phrase it thus in HELP:
- at most one of A[ccess], C[reation], and W[rite] time - default: W
- at most one of B[adly localized: explorer/TCC style], L[ocalized], and U[TC] time - default: L
- at most one of A[ccess], C[reation], and W[rite] time - default: W
- at most one of B[adly localized: explorer/TCC style], L[ocalized], and U[TC] time - default: L