|
|
Joined: Apr 2006
Posts: 464
Fjord artisan
|
OP
Fjord artisan
Joined: Apr 2006
Posts: 464 |
Why is the use of dates/times so difficult in mIRC? I'm trying to find all records that have been added in the last 24 hours, but the comparison between current date/time and the one from 24 hours ago doesnt work.
alias recent-record-stats {
var %cnt = 1
var %tbl = records
var %ttl = $hget(%tbl,0).item
var %start-date = $+($calc($asctime(dd) - 1),/,$asctime(mm/yyyy))
var %start-time = $+($calc($asctime(hh) - 2),:,$asctime(nn:ss))
while (%cnt <= %ttl) {
var %data = $hget(%tbl,%cnt)
var %date = $gettok(%data,11,9)
var %time = $gettok(%data,12,9)
if (%start-date %start-time > %date %time) {
do stuff
}
inc %cnt
}
}
Does anyone know how I can get something like this to work? Thanks in advance!
|
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
Save yourself some trouble and use time in $ctime format. Just convert your date/time to $ctime and check it that way. You'll want to convert your hash table's date/time when setting those variables as well unless you don't mind storing the date/time in the hash table in $ctime format.
Invision Support
#Invision on irc.irchighway.net
|
|
|
|
|
Joined: Apr 2006
Posts: 464
Fjord artisan
|
|
OP
Fjord artisan
Joined: Apr 2006
Posts: 464 |
Alright, at the moment, I have no experience with $ctime at all, but I do think I understand it.
$asctime($calc($ctime - 86400),dd-mm-yyyy HH:nn:ss)
Should return current date/time minus 24 hours.
I'll proceed with this.
Thx Riamus!
|
|
|
|
|
Joined: Oct 2005
Posts: 1,741
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2005
Posts: 1,741 |
Ideally, you should be storing the date/time as ctime always, and then converting it if you need to display it at some point. As you have discovered in your code, it is a nuissance to have to convert a dd/mm/yy hh:nn:ss time format whenever you need to perform calculations or comparisons. So, the easiest solution is to avoid the excessive conversions by using $ctime.
$ctime is simply a number that represents the number of seconds since Jan 1 1970. That is really all (or more) than you need to know. Simple comparisons are all you need when seeing if one is a certain amount larger or smaller than another. Example
if (%ctime.a > %ctime.b) echo ctime.b happened first
if ($calc(%ctime.a + 60) > %ctime.b) echo ctime.a happened at least 1 minute after ctime.b
etc.
-genius_at_work
|
|
|
|
|
Joined: Apr 2006
Posts: 464
Fjord artisan
|
|
OP
Fjord artisan
Joined: Apr 2006
Posts: 464 |
Ideally, you should be storing the date/time as ctime always yeah I realise that now. Thing is, I never understood $ctime because it looks weird. Unfortunately a big and important hash table that I use, is build up with tokens. So, melting token $date and token $time into one token $ctime leaves me with a problem, since everything will jump 1 token back  But I'll think about a solution for that, since obviously storing it using $ctime is the way forward. Thanks for your explanation in any case!
|
|
|
|
|
Joined: Oct 2005
Posts: 1,741
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2005
Posts: 1,741 |
Simply make a conversion script that converts
<date> <time> <information>
to
<ctime> . <information>
A meaningless token can be inserted to occupy that extra space. Just make sure you /hsave a backup of your hash before you try working on the conversion script.. just in case.
-genius_at_work
-genius_at_work
|
|
|
|
|
Joined: Aug 2004
Posts: 7,252
Hoopy frood
|
|
Hoopy frood
Joined: Aug 2004
Posts: 7,252 |
$ctime($date_token $time_token) will return the equivalent $ctime, presuming, of course, that the $date_token and $time_token items are in a valid format. If they aren't, then 0 will be returned.
|
|
|
|
|
Joined: Apr 2006
Posts: 464
Fjord artisan
|
|
OP
Fjord artisan
Joined: Apr 2006
Posts: 464 |
Yeah, I have that in place now indeed.
$ctime(%date %time)
Additionally, I've noticed that in my table, there is actually only 1 token behind the %date and %time tokens, so I only have to modify that particulair token to make it compatible. Shouldn't be a problem.
|
|
|
|
|
