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