I wonder if I can retrieve the Unix Timestamp with the GET object and if so how?
Unix Timestamp:
http://www.currenttimestamp.com/
https://en.wikipedia.org/wiki/Unix_time
Printable View
I wonder if I can retrieve the Unix Timestamp with the GET object and if so how?
Unix Timestamp:
http://www.currenttimestamp.com/
https://en.wikipedia.org/wiki/Unix_time
yes, here's an example:
Attachment 19981
will work as long as:
1) the source page is not modified
(which I have no idea if could happen!)
2) the number of digits will remain the same
(should not happen before about next 8.537.022.567 seconds XD)
Thank you Schrodinger! It is a little to insecure if it would break if the source page would change though. This is for a mobile game so it would be bad to rely on something that could mess up the game if a 3rd party I have no control over changes something.. :/
Do you know of retriving the dates from the date and time object and then converting it to unix time?
Btw, I am trying to get the unix timestamp for the Android runtime. In windows and iOS I can use the iOS timestamp object, but that does not work on Android :(
I see, agreed, a bit unsecure relying on an external page you can't control.
(btw, if you have your own webpage, maybe you can setup your own reliable page to output that?
Look like php has a "time" function that should output Unix timestamp,
if you use other application languages, maybe there are alternatives for that?)
Theorically you could calculate the Unix timestamp with the Date & Time object (android compatible)
the hard part would be getting the date difference in "number of days" (without having an apt function) from 1 jan 1970 to current date.
worse part being taking into account leap years, and counting correctly days in months of current year.
Should be definitely doable, but would require a little thinking-tweaking...
Hmm would it be possible to calculate it if it is only for 1 year max? I would not really need to account for if someone have been away for 5-10 years. In my game there is a cap anyway so people will not be able to get any more bonus if being away for longer than about 24 hours.
As for php I have really never used it :/ I did follow Jeffs highscore tutorial once that was some php I think, but that is pretty much it.
Tried something:
Attachment 19986
(second string is calculated timestamp, first string is the old timestamp retrieved with get object)
not sure it's 100% correct, have to go now but may take a deeper look later
problem is: Unix time is calculated on UTC time, so you should need to know also which timezone your user is in, to apply some hours shifting
(and could be simplified reducing loops just by storing current unix time as of now, and calculating difference from now on...)
Thank you Schrodinger!!
I will test a bit with this, my only fear is if the loops are a bit to heavy on the performance on Android, but I hope not (I need to save the timestamp every minute or so) How do you mean it could be simplified?
About UTC time, I don't know if that will be a problem though? What I am using this for is that I save the users timestamp every 1 minute or so, and then when they return to the game I retrieve their saved timestamp and compare that to the current timestamp to see how long they have been away and thus calculating how much money they resieve depending on how long they have been away. So since I am always comparing the users old timestamp with their new timestamp, timeszones and such should be no problem ? (Unless they move across timezones of course, but that I will not worry about :P )
Simplified because it actually does the calculation starting from 1970 to current day,
but we could just store unix time at (today) and just calculate the difference from (application day) to (today)
saving about 46 loops (in 2016).
From what you say I'm under the impression you may not need unix time,
but some other infos would be useful,
you need to determine "offline" ho much time has passed since the user left the game, right?
And this time must be measured in ... seconds/minutes/hours/days..?
This may happen after a very long time (like weeks, months..)?
Or you have a maximum "cap" of time? (I read 24 hours above?)
We could use a similar approach of previous example just by looping from saved date to current date,
adding minutes/seconds whatever, without converting to unix time,
will be easily much shorter for loops.
I think Julian days could be used to perform date differences also, without having a proper "datediff" function:
https://en.wikipedia.org/wiki/Julian...ian_day_number
would need no looping at all but jus a couple well laid expressions
(btw, Unix time would break from 2038, if Fusion3 won't support 64bit integers / if Fusion 3 won't be out by 2038 >:)XD)
Hmm I don't think I would need from 1970 no :p I dont see how that would be useful. The game will be released 2016, so starting from 2016 would be enough? It needs to work 2017 forward of course also though. But yeah 2038 does not matter... :P There is not really any hard cap, but very very very very veeeery few players will have a cap over 24 hours. To be safe it might be good to set the cap at 48 hours though.
The reason it would be nice with unix time is that I have already my calculations ready with unix time for the iOS version with the iOS timestamp object, so if I could get unix time here also I would not have to redo the calculations for how much gold to give.
How would you go about to simplify it in regards to the 1970 and all the loops that could be removed?
The 1970-to-today thing needs to be stored because unix time starts at 1 jan 1970,
the unix time is seconds elapsed from that day to now,
so wether we calculate it (example above) or calculate and store it up to now, 1970 must be taken into account XD
Ahhh I see, if you are bounded to use unix time, we could store unix time at 1 jan 2016
and then just add the difference looping from that date to (now)
would save us from looping since 1970 :)