Attempting to convert numbers into dates

[Nælü]

Hello

I'm attempting to convert numbers into dates, and am having trouble doing so.
I've tried using number and date formatting, along with getDate([Number]), but I'm not getting the results I need.

The numbers are in milliseconds, like all default dates.

[Desmanto]

getDate() require no parameter or at least 2 parameters. Tap the function at the script and find getDate, to see which parameter it needs. To convert miliseconds number to date, you can use addSeconds() with 0 (to force it evaluated to timedate) or use getDate() with pattern "S" (S for miliseconds).

Code: Select all

t = 1540123456789;
a = addSeconds(t,0);
s = getDate(t, "S");

Attach condition debug dialog to see that {a} and {s} has been converted to time.

[Nælü]

Thank you !

I tried using the addseconds command like so : addSeconds(t,0); but it didn't seem to work for me.

The getDate one did, though, I wasn't using quotes, which gave me an error. It's not entirely clear in the help documentation that quotes are needed, however.

[Nælü]

Neither are working anymore.
I'm using a date and time input for the first variable.

Here's what I did to test :

Code: Select all

a = {value};
b = getDate(a, "S"):
c = addSeconds(a,0);

The values are :

Code: Select all

a : 838799520000
b : -3599162
c : 838799520000

I'm not sure what's going on, but it likely has something to do with the "S".

16h21 : It turns out I had an adding error somewhere, AND, more interestingly, dates simply don't show up in date format if they're under a certain amount. I haven't found out what that amount is, exactly, but it's around Novembre 1998, or 909874800000.

[Desmanto]

Sorry for the pattern "S" version, it doesn't work anymore. I forgot since when, but I remember Martin ever said that was deprecated already by android itself. I remember it is not working anymore in LP 5.1. Suddenly it is working again in my current phone Oreo 8.1, I thought it is added back. Turns out, I miss-read the variable in the debug dialog. I replace the naming before pasting here, so {s} also become some minus number at my phone now. To use the pattern, you must use "s", which translate to seconds. But because the number is in miliseconds, you have to divide by 1000 and plus back the modulus of t by 1000 (add back the miliseconds).

Code: Select all

s = getDate(t/1000, "s") + t % 1000;

But this code have a problem, it will deduct back your timezone to show the time in UTC+0. I am in UTC+7, so the s is 7 hours earlier compared to t or a. You can add back the timezone by using another formula, but I am going to confuse you further if I do so. Better use addSeconds().

Now to your problem. If you use t = 1540123456789, you will get it correct for the addSeconds() version (the pattern "S" doesn't work anymore). But if you use 838799520000, it doesn't work. I trace back and try to increase your value and reduce it again to find since when it start not working. Retrace back until year 2000, back to 1999, and beyond 1998 suddenly not working. I tried the months also and after several ten of testing, finally realize it is 20 years back. So the time only converted when it is 20 years back from current time. Not exactly, but it is 20 x 365 days. At mine it is 6 November 1998 (tested on 1 November 2018). You can try this

Code: Select all

past = addSeconds(getDate(), -20 * 365 * 86400);
converted = addSeconds(getDate(), -20 * 365 * 86400) + 1000

{past} is not converted, it just shows up as number. While {converted} is converted to date even though it is just 1 second later than {past}. But if you try bigger number than that, you don't have limitation for 20 years to the future. You can increase until year 2100 without any problem.

Without your testing, I will never know such bug (or feature) exists. I don't know whether this 20 years auto convert is a bug or featured. Also don't know whether this is Automagic's limitation, Java or android itself. I can see the reason behind it, so it doesn't instantly convert any big number to datetime data type. It will be annoying to have your big numbers suddenly changed to time type without our knowledge.

EDIT : it seems you have figured it out too