Hello,
This is actually the expected behaviour. All dates are persisted as date times in the server's timezone. Therefore on the way in, all dates need to have a time associated with them and this time is then correctly modified from the user's local time to the server's local time and persisted. On the way out the reverse happens, with the persisted time and date being converted to the user's local time and date by Share's client side code. The two times you've listed refer to exactly the same time, so it appears that the date entered is being persisted correctly.
If you're seeing an issue with how that date is displayed in the UI, then it's possible there might be a bug - this is an area that it's hard to test and there might be some issues (especially surrounding custom metadata) that have slipped through our QA. This is an area that improved massively between 3.4 and 4.0 and has continued to be enhanced through to 5.0. You're likely to find any display issues have been fixed in more recent versions. However, if that isn't the case, we'd appreciate it if you could raise a JIRA and then we can fix any rendering issues that still exist.
If you've written any custom UI renderers for your metadata, you'll need to ensure that the date returned from the API is parsed by Alfresco.util.fromISO8601 on the client side.
David.