You're on the right track with the *CONTEXT* clause, but unless you've created it, *utc_i18n* doesn't exist. If you want to create an i18n value for UTC, check out the documentation on [Managing Internationaliztion Configurations](https://community.denodo.com/docs/html/browse/6.0/vdp/vql/advanced_characteristics/creating_new_internationalization_configurations/creating_new_internationalization_configurations#managing-internationalization-configurations). However, there are a couple of simpler items you may want to look at first. (The [FORMATDATE](https://community.denodo.com/docs/html/browse/6.0/vdp/vql/appendix/syntax_of_condition_functions/date_processing_functions#formatdate) function should not be necessary.)
The first thing I would look at is the Base View that this date is coming from. Even though you aren't storing a timestamp in the source, the source database has a time zone setting and, depending on the RDBMS, may be storing the date field with a *00:00:00* (midnight) time stamp attached. This midnight timestamp could be getting offset from the intended UTC value before you even query it. On the *Search methods* tab of the *Options* on your Base View, the *i18n* value is likely set to the default value for your VDP server. If this is different than the source, you could set it to match as outlined in the [Internationalization Configuration](https://community.denodo.com/kb/view/document/Internationalization%20configuration%20and%20dates?category=Common+Errors) article on our knowledgebase.
Since in your case you don't want the timestamp at all, I'd also take a look at the [Schema of the Base View](https://community.denodo.com/docs/html/browse/6.0/vdp/administration/creating_views/importing_data_sources_and_creating_base_views/viewing_the_schema_of_a_base_view) and edit the field type. Even though it has the field type *date*, if you click the edit (pencil) icon next to the drop down, you'll be able to choose whether this field should be represented as a *DATE*, *TIME*, or full *TIMESTAMP*. In your use case, I'd suggest changing it to *DATE*.
Depending on what tool(s) you are running your query from, there could be an application level setting forcing a time zone conversion. If you check the Base View settings I mentioned, you should get the results you desire, but your reporting tool or client app could be overriding that. In such a situation, your *CONTEXT* clause specifying an i18n value may be necessary, but as mentioned above, *utc_i18n* would need to be created if you haven't already.
Hope this helps!