getDate and "{x,dateformat,x}" error

[soutre]

I'm having some trouble to convert a date and time. It seems to either result in an error or the same variable is returned.

These two values are the original data examples. Dateformat doesn't work on them.

Code: Select all

timeA="2019-08-19 06:00:00"; //Regular format

timeB="1566194400" //Epoch time

However, as I only need the time, I used regex to extract the time from the Regular format string.

Code: Select all

timeC=findAll(timeA,'\\d{2}:\\d{2}');

timeD="{timeC,dateformat,hh:mm a}"

//timeD results in "22:00" which should not be correct based on the format options.

So I tried manually typing the time.

Code: Select all

time="{"22:00",dateformat,hh:mm a}"

And the result is still "22:00".

My next step is to create a formula to convert the time into the form I'd like (hh:mm a) but just want to reach out and see if there's a flaw with my approach.

Finally, I'd like to add that the date from getDate() will convert just fine.

Anyone else experiencing this same thing and how did you go about approaching it? Thank you for taking the... time.

[canadaDry]

Try this:

Code: Select all

timeB='1566194400000';  // note the added '000' on the end (android epoch is in millisecs)
timeD="{timeB,dateformat,hh:mm a}";  

Should result in timeD = "02:00 AM".

[soutre]

Looks like I'll be multiplying the value by 10000 to add the 4 extra zeros before formatting.

Code: Select all

timeA=1566194400*10000;
timeB="{timeA,dateformat,hh:mm a}"

Not so fast! After testing that, the time was substantially off. And it got me to wonder. The time is missing 4 digits and time zones are also...4 digits. So this lead me to conclude the epoch time is intentionally lacking 4 digits for the reason of a time zone. I got a more readable time by multiplying for 1000 but it was still off.

Combining your idea with this concept, the final solution is working:

Code: Select all

zone="{triggertime,dateformat,z}"; // Why get a new date?
timeA=1566194400;
timeB=timeA*1000;
timeC="{timeB,dateformat,timezone,zone,hh:mm a}";

And all this to reconsider my need for a time to begin with. Thank you sincerely for the help!

[Desmanto]

As I have just explained it here : viewtopic.php?f=5&t=8207
Automagic stored time in android millis. Your timeB is unix epoch in seconds. So you have to times 1000 to get the miliseconds.

You can't use regex to match the time, because timeC will now become a list with content [06:00]. When forced to dateformat, it won't change (don't know why you get "22:00").
Using manual typing time also won't work, because "22:00" is a string, while dateformat expect a number.

You can use the number directly such as

Code: Select all

time = "{22*3600000,dateformat,hh mm a}"

But since I use UTC+7, instead of 10 00 PM, this give me 05 00 AM (which is 22 + 7 = 29, then rolldown to 5)

Converting from external source millis or manual calculation is always a problem. You have to know the timezone based for the millis that you get. Most of the time, the external source will output it in UTC+0. So you simply have to add with your timezone.

To get the millis of the timezone, you can use this

Code: Select all

tz = -getDate("{0,dateformat,z}", "z");

This get the base 0 timezone and convert it back to time to get the timezone difference in miliseconds. In my case, UTC+7, is 7 hours after UTC+0, so tz is 25200000 here. Add tz up with the millis that you get should get you the correct time you need based on your timezone.

Code: Select all

tz = -getDate("{0,dateformat,z}", "z");
timeA = 1566194400;
timeB = timeA*1000;
timeC = timeB + tz;
timeD = "{timeC,dateformat,hh:mm a}";

Your method still works for your usage case. Mine save the timeC directly in current timezone, so you can do more calculation later and only output it to "hh:mm a" when needed.

[soutre]

So it stores in milliseconds that must be why. The dateFormat is becoming more interesting. Here is the formula I'm using to convert the dates. Using the string "2019-08-20" as an example. Automagic isn't able to format this date either. So first we must convert it into epoch time. Just the time in seconds between now and 1970-01-01.

Code: Select all

d="2019-08-20";

Starting date

Code: Select all

ey=31556926*1000; em=2629743*1000; ed=86400*1000;

For epoch, seconds in year, month, day with millisecond adjustment

Code: Select all

f_yr=findAll(d,'\\d{4}'); f_md=findAll(d,'\\d{2}');

Find year, month and day in original string

Code: Select all

year=(f_yr[0]-1970)*ey; month=(f_md[2]-1)*em; day=(f_md[3]-1)*ed;

Adjust the date values for epoch time

Code: Select all

epoch=year+month+day;
date="{epoch, dateformat, EEEE, MMMM dd'th}";

FInally

--> Should result in: "Tuesday, August 20th"... Yet it seems like this is a bit complicated and it makes me wonder if I'm missing something substantial.

[Desmanto]

That is interesting. I haven't gone that far yet. But surely it will add up to the millis.

Automagic has 6 getDate() functions. My favourite 2 are getDate() to show current time and getDate(date, pattern). Actually you can easily convert the date using pattern.

Code: Select all

d = "2019-08-20";
epoch = getDate(d, "yyyy-MM-dd");
date = "{epoch, dateformat, EEEE, MMMM dd}th";

Behind the scene, probably Automagic convert the pattern as what you have done above.

[soutre]

That is interesting. I haven't gone that far yet. But surely it will add up to the millis.

Automagic has 6 getDate() functions. My favourite 2 are getDate() to show current time and getDate(date, pattern). Actually you can easily convert the date using pattern.

Code: Select all

d = "2019-08-20";
epoch = getDate(d, "yyyy-MM-dd");
date = "{epoch, dateformat, EEEE, MMMM dd}th";

Behind the scene, probably Automagic convert the pattern as what you have done above.

Well that means the second parameter is not a format but rather the input of the original date. That makes more sense to parse it into more usable data since dates seem to have all sorts of configurations. Looks like I'll need to revisit my flows and change these ludicrous date format schemes. Very good insight.