[Resolved] unix timestamp change

[Author]

Posts

[mikeH-3]

I am using a date custom field (wpcf_date_preached) for a custom post type (sermons). My admin assigns a date to his preaching using this field. So if he preaches on Sunday, Sept 15, 2019, your program puts in this number "1568505600" which I guess is UNIX timecode. That works for the website. But when I export this data using REST API, my mobile app converts that number to my own time zone, which 1568505600 converts to Saturday, September 14, 2019 8:00:00 PM GMT-04:00 DST instead of Sunday, September 15, 2019.

My mobile app cannot adjust times to anything but my own time zone, so I have to figure out a way to have TOOLSET output the exact date and time in the REST API that is put into this field, regardless of time zone. How do I do that? Why can't it output the same format as the post_date field? Like this: hidden link

[Beda]

Yes, this is a Timestamp value, used by Toolset to store dates you choose in the Date field offered by Types (or Toolset Forms).

It is also what's used by Views, to compare dates when you use Custom Fields (hence there you would compare dates as a NUMBER), might be useful to know in your project.

Related to the issue you describe, this depends upon the App consuming the data from the REST. Assuming the App can understand Timestamps and knows it receives a Timestamp, it will then convert this to a human readable format and display that.
This logic happens on the App side, when the App consumes this data. Hence, transforming that timestamp to a human readable formate in the right timezone is as well up to the App.

I am not sure how you programmed the App or where/how it runs, assuming a WordPress Plugin, you would simply use some PHP Core functions to convert the timestamp to a proper timezone formatted date and display that.

You need to know, when programming that App, that Toolset will always store UTC to the database no matter what your WordPress > Settings timezone is.
Let me explain this better.

You have a timezone setting on the server, another on the WordPress installation.
You can edit one of them (WordPress) but usually not the other.
But changing one of them or both we expect different outcomes on different things.

WordPress itself stores its dates in two "flavors":
- the local date according to the WordPress timezone settings in your install,
- the generic date according to either GTM or UTC (I am not 100% sure, to be honest, which one it is).
Then, WordPress adjusts the value displayed, based on those 2 values.

Now, Toolset stores timestamps as mentioned, and in either case Toolset could not satisfy all needs:
- Toolset could adjust the timezone for the fields depending on the timezone settings on the server. However, it's most likely that most users will demand to adjust it based on WordPress timezone settings.
- hence Toolset could adjust the timezone for the fields based on the WordPress timezone settings. However, just as probably as above, some users will demand to adjust them based on the server settings.
- Toolset could also adjust the value on render time (so, not when it's saved but when it's shown) - and apart this would not help in the EST case, and even offering both of those timezone settings the same principle applies:
some users will want Toolset to adjust it based on the other setting. The GUI for that would simply be too bloated.
In addition, querying by this field will become very problematic, since the displayed value may differ from the stored value or even usage of several different settings, might then break views.

Generally, a timestap is related to UTC, so Toolset saves those dates you input always in UTC.
There is something peculiar about it, that when you (no matter where or what your WordPress settings are) enter a date and time in the Toolset Date field in the backend, you in fact enter a UTC time. If you look on your phone right now and copy that time to a Toolset Date Field, the database Timestamp stored will be the exact time but in UTC. So if you typed in 01/01/2019 12:00 then it stores exactly that but since timestamped are UTC, it'll be UTC, and converting it back to "local" will mean you see 01/01/2019 20:00 if you are in Asia, or 06:00 if you are in America.

Now, when you display such a Date, it will display what you entered in the backend, so if you entered 01/01/2019 12:00 you will see exactly that if you insert [types field='your-date-field' style='text' format='F j, Y h:m'][/types] somewhere.

However, a person in Asia, or a person in America will both see the same (in WordPress).
You'd need to communicate to the visitor, "hey, the dates are to be understood as xy timezone".

So if you produce a website for someone in your timezone you can simply forget about it, if they have visitors from outside the timezone, you'd need to mention to them, that the time is not within their zone.

In the App, you will need to program the App so that it understands this too, and best, just convert the timestamp it receives as the PHP function date does:
hidden link

As said, I am not sure how you program the app, if you use PHP; that would be the function to use.

I hope this covered all doubts, please let me know if not!

[mikeH-3]

Wow that was very nice of you to go into that much detail to tell me why it's like that. I appreciate it. So, now that I know why it's like that, I still have the same question...

My mobile app cannot adjust times to anything but my own time zone, there is no way around that. I don't control the app code. So I have to figure out a way to have TOOLSET output the exact date and time in the REST API that is put into this field, regardless of time zone. How do I do that? This has to be the json data it exports. I know I can change the formatting of the date if I wanted to show it in the website. Did you tell me the answer somewhere in here and I missed it?

Thanks! Mike

[Beda]

That is not possible, just as it is not possible to alter Code in an App that does not allow to edit its code.
The REST API gets the values from the database. The database stores those timestamps, and there is no provided method to alter that on the fly before it gets consumed by the API of the App.

What you can do is store a field with a value that your app can read, along with the Toolset Date field, and call that instead.

You could do that when you create/edit the posts, by automating it with a Custom Script.
I can partially help with that, for example you could create a Post Form and add a cred_save_data() function to update a new custom field with the exact value your app can read and display properly.

The conversion to that format or timestamp however is not something that Toolset can help with, it would require custom code, that then is as above explained, hooked to cred_save_data and uses update_post_meta() to update the Posts new field.

I can help with this part, please let me know if you need help with it.

The Toolset related DOC and WordPress codex you will need are:
https://toolset.com/documentation/programmer-reference/cred-api/#cred_save_data
https://codex.wordpress.org/Function_Reference/update_post_meta

[mikeH-3]

Okay so my client enters in the date of sermon. This is stored as UNIX code in the json file. That is just how the process works.

So... I guess what I need then is a field that will also display in the json file that has converted that unix code into an actual usable time my app can read. So how would I do that?

Something like this? https://wordpress.stackexchange.com/questions/229474/converting-unix-timestamp-to-wordpress-date?rq=1

But how do I get that to show this value it converts into my json file for this custom post type?

[Beda]

I cannot help with this, because it is outside of Toolset's range.

Toolset can help you to create that field (in Toolset > Custom Fields you can add any kind of field).
It will not be a date field, but some single line field to store whichever format AND timezone you need for your app (remember, this is not related to the format at all, it's related to the timezone).

Remember that the time you get from Toolset currently is your current time you read off the clock and insert in the field, but assumed UTC zone.

So wherever you are in the world and whatever the settings of WordPress, it will save 14:06 of 01.01.2019 if that is what you entered in the date field, and it is what will be displayed.

No matter where you read that information, it will always be 14:06 of 01.01.2019, and unless you state on the website some particular detail, the user obviously will assume his local timezone, I think.

So the right thing here is to state where the time is assumed of, and display the date you get from Toolset.

In any case, if you need/want to do that, you can as explained previously use hidden link to convert any date to any other date.

This could be done either in the save_post() hook if it needs to happen in the backend when saving the post or in a cred_save_data() hook if it should happen in a Toolsets Form.

Something like

function my_func( $post_id ) {

	// If this is just a revision, don't send the email.
	if ( wp_is_post_revision( $post_id ) ) {
		return;
        }

	//put checks in place if needed

        //Get the values (for example get the date field and convert to whatever you need: https://developer.wordpress.org/reference/functions/get_post_meta, <em><u>hidden link</u></em>
        $field_slug_existing = 'wpcf-your-existing-field';
        $field_slug_new = 'wpcf-field-slug-new';
        $new_value = date( 'format' ,get_post_meta( int $post_id, $field_slug_existing, true ) );//Edit format to what you need, and get_post_meta to get the date field of toolset

        //The actual action to update a field in the database with whatever other value: https://codex.wordpress.org/Function_Reference/update_post_meta
        update_post_meta( $post_id,  $field_slug_new, $new_value ); //update the new custom field with the value you got above

}
add_action( 'save_post', 'my_func' );

Note, above code needs adaptation, it only outlines the process and methods to use.

If you require more assistance wit custom code, I would suggest consulting the contractors here https://toolset.com/contractors/

Please let me know if anything remains unclear.

[mikeH-3]

Thanks for the help! When I put that code into functions file, it crashes my website. It looks like it is this line that does that:

$new_value = date( 'format' ,get_post_meta( int $post_id, $field_slug_existing, true ) );

Do you know why?

[Beda]

I mentioned that above code needs adaptation, it only outlines the process and methods to use.

We do not prepare code to copy paste in the Support Forum of Toolset (https://toolset.com/toolset-support-policy/).
We can give examples, that need to be adapted, according the related Documentation which we share when we add such examples.

When you consult my code snippet I have given as example you will find inline comments such as "//Get the values (for example get the date field and convert to whatever you need: https://developer.wordpress.org/reference/functions/get_post_meta, hidden link"

These 2 links point to WordPress functions used and also the date() function used.

The entire code needs to be understood and edited, so to match and perfectly fit in the existing site you have.

I can unfortunately not provide ready to go code, I can only assist with examples, docs and there-like.

When working with custom code you should do so on a staging site, and turn on WP Debug, then the error will tell what line of the code is faulty and what is faulty in it.
Now, it seems you narrowed it down to $new_value, and there we use the date() function, but I did not specify any valid "formats" in the function, as seen when consulting the related PHP Doc there are so many, that you will need to choose your own.
hidden link

Then, in the same function I choose as second argument the timestamp we get from the database (so the value saved in our date field)
That means date() here will convert the second value to the format passed as first value in the method.

I get that value with get_post_meta( int $post_id, $field_slug_existing, true ) , which is a WordPress core method to get post fields values.
It needs a post ID which here we can get from WordPress save_post API $post_id variable.
(I made a typo there, I forgot to remove the "int")
Then, it requires the Field Slug, which I create earlier, with $field_slug_existing. That of course needs to be edited so to match the exact slug of your field, as shown in the code example. Remember that the Toolset custom Fields all have a wpcf- prefix to the actual slug.

Please find the code below again (it still needs to be adapted) but without the bad typo:

function my_func( $post_id ) {
 
    // If this is just a revision, don't send the email.
    if ( wp_is_post_revision( $post_id ) ) {
        return;
        }
 
    //put checks in place if needed
 
        //Get the values (for example get the date field and convert to whatever you need: https://developer.wordpress.org/reference/functions/get_post_meta, <em><u>hidden link</u></em>
        $field_slug_existing = 'wpcf-your-existing-field';
        $field_slug_new = 'wpcf-field-slug-new';
        $new_value = date( 'format' ,get_post_meta( $post_id, $field_slug_existing, true ) );//Edit format to what you need, and get_post_meta to get the date field of toolset
 
        //The actual action to update a field in the database with whatever other value: https://codex.wordpress.org/Function_Reference/update_post_meta
        update_post_meta( $post_id,  $field_slug_new, $new_value ); //update the new custom field with the value you got above
 
}
add_action( 'save_post', 'my_func' );

Note that the code above still cannot be used as is. For that type of customization, we can only refer to https://toolset.com/contractors/, where you can look for professional custom code assistance.

Please let me know if any of the particulars is unclear.

[mikeH-3]

I don't understand.. I left a message on here days ago and have been waiting for a reply, and now I don't even see it.

Since this code isn't working for me, would a function work that just saves my timestamp 10 hours ahead? Something like:

if date_preached field is entered as 1570060800, put in 1570096800 instead?

[Beda]

What do you mean with the message you left here days ago, and a reply you got but cannot see?
Do you mean you posted here as an answer to https://toolset.com/forums/topic/unix-timestamp-change/#post-1348749, and that this reply got lost?

The only last reply I have from you in the logs is https://toolset.com/forums/topic/unix-timestamp-change/#post-1348357.

I hope it was not important details, I suggest to copy paste or at least copy the content before sending in the next time (just for safety).
I cannot see any log for further replies, which makes it difficult to pinpoint the issue of the forum here, if there is one.
Do you recall exact date and time of your reply?
That can help.

Now to the issue you follow up with:

1. Since this code isn't working for me, would a function work that just saves my timestamp 10 hours ahead? Something like:
"if date_preached field is entered as 1570060800, put in 1570096800 instead?"

This can be done on save_post() or a cred_save_data() hook, you can alter the saved data.
So for example, if in a Toolset Form you'd use cred_save_data as above shown already, just this time add some time to the value and update the post meta with that.
Or, similarly in a save_post() action.

All this is still subject to custom code, because Toolset does not offer such features out of the box. The same code as provided above for the save_post() can be used, but you need to change the Custom PHP Code in it to add time to your existing field input.

2. If the code I shared does not work, neither will a code that does some other kind of manipulation to the data. You need to enable WP Debug, and start to debug the code (var_dump the variables to see what you get, and what you send). Then eventually it will show that there is some error somewhere, maybe a slug is not correctly getting the existing slugs of your site, or other.
Just as before it was a typo in my example code, it might be some value that is not in the format as expected, or other - knowing what error happens already can help pin point it.

I recommend however if you have no experience with custom code, and require this functionality, to contact a contractor from https://toolset.com/contractors/, for example, to resolve this. In Toolset support we can unfortunately only be of limited assistance with custom code.