The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
I prefer some variation on yyyy-MMM-dd, although for some cultures it may be yyyyy-MMM-dd or even yyyyyy-MMM-dd. But that's because I like easy sorting, something that is easy to do with a computer but not so easy in a paper ledger.
If you know that the application is going to be used on a system that supplies a default date formater, always use that. If the user doesn't have it set to what they like at least it will be consistent with most of the other software the user uses.
Or you can work in an industry that specifies the format that everybody has to follow. In my case that is ddMMMyy or ddMMMyyyy both of which are pain to sort if all you have is text.
But to answer the question...
For a legacy UI that you don't have time/budget/permission to recode and regression test, stay with the same format of data display. Changing it for your piece will generate user irritation because it is different, or will make them irritated with the older portion because it's not as nice as the new part.
For new code, use system defaults. Maybe add a section to documentation about setting the system date. Of course that has it's pitfalls as well.
Yes we have a responsibility when creating a UI. You seem to be forgetting what the U stands for. When people talk about dates, people will say "June Seventh" way more often than they say "Seventh of June". Also when presented with a list of dates, having things in mm/dd format makes them more easy to compare at a glance. If you are designing middleware you can be as logical and unambiguous as you please. But if you design a UI and prioritize your personal sense of logic and order above what the users feel is comfortable and familiar your design will be a failure.
The way american Papuan speaks has nothing common with how it should be written. If you see time "10 hours 12 minutes", IT IS NOT "thousand twelve", whatever military people say. Feel the difference? Same with dates, especially when only crazy USA has clumsy order "month day year".
Normal order is "day month year". Day number is more important than year. And if you exchange dates with other people, think twice before you force 'em to scratch head with your "17/7/17".
Universal date is quite simple: "dd MMM yyyy". No mistakes, no fighting, suits for much more people than living in america.
Your time example actually proves my point more than yours. The format you like: dd/mm/yyyy is in decreasing significance order, meaning most specific to least specific. So if you were to extend that with time then it would be ss:mm:hh dd/mm/yyyy. But I am sure that seems ridiculous to you. We all use cultural rules when choosing how to display data. Do you also insist that in languages that are read from right-to-left that they should switch to left-to-right because you feel it suits more people? If you were designing a UI with a status indicator and you chose a fairly standard red/yellow/green scheme would you refuse to change it after finding out your users were colorblind because the scheme suits more people? The point is that it is how your users feel about the way data is presented that matters. That is a higher responsibility than adherence to rules you feel are "universal".
Yes that works just fine unless they speak only Russian, or Chinese (which accounts for quite a large number of the humans in the world). The fact that you TLDR for a single paragraph means you have no interest in learning anything and are willing to stay ignorant. Good luck with that.
Just try to implement dd-MMM-yyyy in many places only to have the [non-technical] "stakeholder" go 'Why is the date f!@#$% up? Go fix that. Our stupid users won't unnerstand'. Yes Biff - going Biff....
Well, it always helps to have empathy towards the end-user in order to achieve as much ergonomic and intuitive programs, but back to your case, the programmer in charge of redacting the database transaction layer is supposed to make sure that the date is stored using a time-stamp, whereas the UI programmer should take care of accordingly parsing this time-stamp on an end-user localization basis so that the end-user can for example always remotely generate a consistent receipt whatever his location.
But yes, both programmers can definitely be the same person. Presenting information to the world in various notations or languages require more UI efforts than using more standardized schemes, but have its charms.
In all cases, if the data is presented ambiguously, then the project is an epic failure (!?), with data dumped to the end-user becoming inconsistent so unusable, but in theory and back to your initial question, inside a project with respective road-maps for several programmers, it would be the UI programmer's job to properly dump / format data that have been consistently stored.
Developers have a responsibility to understand the system that they are building, and preferably before they start building the system IMHO. How the system is intended to be used (via a User Interface), and by whom, is part of that understanding. Therefore the answer has to be 'Yes'.
Wow, I was surprised that this is even a question but pleased so many believe they are responsible for a user-friendly UI.
Absolutely, even if the programmer is given specific specifications, they need to validate what the user experience will be. We do not program stuff just to move data around. Ultimately a user must interface with the information and when they do, it should be as intuitive as possible. Nothing is more crazy making for the user than a UI that is confusing or ambiguous when the designer and programmer (and the whole team) have the power to make clean sensible user experiences.