SQF generate UNIX timestamp?

[Tethlah 0]

I have a function on our server where players can get a loan, and once a day it'll pull 2% of the original loan value out of their bank account until the loan is paid off.  We restart the server every 4 hours, so none of this can be stored in variables, it has to be stored on the server.

 

My issue is that right now they get charged 2% every time they come into the game (the loan repay script is in the init for the player).  So I want to add a check to see if they have made a payment that day when they log in.  My thought was a simple conditional where when the script runs, it generates a unix timestamp.  It then compares that timestamp against the player's last payment on the database, if it's been 24 hours then the script deducts the payment and then replaces the old timestamp with the new, if not, then it doesn't do anything.

 

Problem is, SQF seems to be the only programming/scripting language I've come across where I can't figure out how to generate a unix timestamp.  Is it even possible?  Like I said, none of this can be dependent on variables stored on the server, so time outs, sleep timers, that sort of stuff wont help.

[badluckburt 78]

I don't think you want to generate the UNIX timestamp in SQF, I don't even think that's possible since you have no access to the current system date there, only the Arma world date.

 

What database are you using? A trigger or stored procedure should be able to help you out.

 

 

[sarogahtyp 1108]

I dont know if a unix timestamp is possible.

I have a suggestion for another solution.

You could use time just at mission end to get the time the mission ran.

If u add that value to the value from last mission which u ve to store at server, than u can have a cotinious mission clock running which isnt restarted with missions restart.
I hope was able to clarify what i mean.

[Tethlah 0]

I don't think you want to generate the UNIX timestamp in SQF, I don't even think that's possible since you have no access to the current system date there, only the Arma world date.

 

What database are you using? A trigger or stored procedure should be able to help you out.

 

I'm using mysql.  I know everything is working where I can do the comparisons and read sfrom the database.  at this point the only thing I need to do is figure out how to get a unix timestamp into the sqf script.  I guess I could write a stored procedure in mysql that gets the current unix timestamp and returns it, then call it from the script as a variable, use it for comparisons and input it into the database if appropriate

[pedeathtrian 99]

No need to write stored procedures for it. MySQL already has UNIX_TIMESTAMP, which for your needs will be used like UNX_TIMESTAMP(NOW()).

 

However, I would higly recommend you not using unix timestamps in SQF unless you're OK with its ~2 minute precision (and not 1 second like you might think).

The reason is Arma Number type which is C float type, which has only 24 (23 real +1 implied) bits for significant orders in floating point numbers. That means you can precisely present integral numbers up to 16777216 (2²⁴), then you got only even numbers, then only 4x, then 8x and so on. At numbers like 1458868810 (the time I'm writing this) you can only present timestamps with interval of 128 seconds! If you're OK with that, then continue, but I would personally offload all datetime operations (and probably all accounting) for database (and MySQL has lots of functions for that).

 

BTW, for the same reason Array and String types have treir size limits, you simply cannot address every array element or char in a string after 16M₂. 9999999 was chosen probably because it's easier to remember for humans.

[Tethlah 0]

No need to write stored procedures for it. MySQL already has UNIX_TIMESTAMP, which for your needs will be used like UNX_TIMESTAMP(NOW()).

 

However, I would higly recommend you not using unix timestamps in SQF unless you're OK with its ~2 minute precision (and not 1 second like you might think).

The reason is Arma Number type which is C float type, which has only 24 (23 real +1 implied) bits for significant orders in floating point numbers. That means you can precisely present integral numbers up to 16777216 (2²⁴), then you got only even numbers, then only 4x, then 8x and so on. At numbers like 1458868810 (the time I'm writing this) you can only present timestamps with interval of 128 seconds! If you're OK with that, then continue, but I would personally offload all datetime operations (and probably all accounting) for database (and MySQL has lots of functions for that).

 

BTW, for the same reason Array and String types have treir size limits, you simply cannot address every array element or char in a string after 16M₂. 9999999 was chosen probably because it's easier to remember for humans.

 

 

Well like I said, the goal is to test the last 24 hours, so 86400 give or take 2 is ok with me.  And like I said, the goal is to simply say if the script has ran in the last 24 real hours, don't run this time, but if it has not go ahead and run.