People generally live their lives within the local sphere. There is a lot said in the phase "My plane lands at Narita at 13:00/1PM" that isn't said in the phrase "My plane lands at Narita at 05:00 GMT".
With the first, I know that the locals are just finishing lunch, it's likely to be the warmest part of the day, and that it'll be busy getting to the hotel, but everything should be open.
Converting everyone to GMT means that every time you leave your region, you need to figure out what time customary activities take place - and you need to do this for every single different place you visit.
Standardized GMT doesn't work unless you are a hermit with no friends or need for communication.
If I'm in New York following the nuclear crisis in Japan, it's probably more important for me to know that the next news conference is two hours from now than that it's in "the morning" there. If I'm planning a meeting I certainly want to know the absolute time it's occurring, and only care about the relative time depending on how courteous I am.
I'm not saying we should stop caring about working hours and daylight hours in various places. I'm just saying that those vary wildly and are dynamic, and we should reflect that in our concept of "time".
But then, I'm a nerd.
India is +5:30, Nepal is +5:45, California observes DST but Arizona doesn't... the EU does, but they start and end DST a week before the US...
It's ridiculous.
The initial gut reaction against this is that people would hate waking up at 18:00 and going home at 8:00, but I think people would get used to this pretty quickly. After all, we do this twice a year as it is.
There is also Namibia which used to lose hours in daylight savings time and Bangladesh which had dst in 2009 then dropped it, this makes historical time calculations tricky.
(Then again, it's the national standard of two whole countries, everyone else ignores it. :-( )
Imperial / kōki which counts from alleged founding of Japan in 660BC
Era / nengō which counts the years from the start of the Emperor's reign
European / seireki adopting the International standard date counting from the alleged birth date of Jesus Christ
Today is 平成23年5月13日 of Mikado Heisei, the 125th Emperor of Japan
Kōki is not used by anyone with a straight face in this day and age.
"Mikado Heisei" is an extremely uncommon way to refer to the emperor. "帝平成" gets 724 hits on Google, and "Mikado Heisei" gets 6, in 5 different languages---the first of which is your post above. Even the Japanese-language wikipedia page on him doesn't use the word "帝" anywhere.
I'm sick and tired of people arguing that you put the month first because "That's how you say it".
Today is the Thirteenth of May, not May 13.
I prefer dd/mm/yyyy to yyyy/mm/dd though, just to keep what is usually the most important information at the front.
1) Sorting the string representations sorts in time order.
2) It eliminates ambiguity almost completely, because extremely few places use YYYY-DD-MM. The ambiguity of most ##/##/## dates is irritating.
No ambiguity, easy to parse and 3-letter month is natural delimiter between day and year numbers.
Besides, often when you write dates you leave the year off entirely.
If only MSSQL Server wasn't broken in the way it interprets that if your user locale is set to UK English (give it a string formatted that way in other locales and the behaviour is as expected, in "English (British)" it sees the format as yyyy-dd-mm).
From memory, the safest format to use is actually yyyymmdd (without the hyphens) though, which is apparently supposed to be interpreted unambiguously by SQL Server.
I had a wonderful stack of little helper functions and views I'd cobbled together at that job and had had free rein to stick into the real databases; they made development so much easier. The downside of employment though, that sort of work gets stuck with each employer you do it for and can't so easily be carried around like a toolkit.
I experimented a bit with some of the code from http://www.simple-talk.com/community/blogs/philfactor/archiv... a while back on some toy projects; it makes some interesting reading and had me building a few similar functions around my own conventions and rules. On a larger scale, I would be sorely tempted to build something like that into the Model database and insist on a clean output as part of the approval criteria.
If you ever find yourself in that situation again, write the UDF as a in-line table-valued function. You get multiple return values and avoid the scalar UDF hit, since the engine will execute it in-line (appropriately enough).
eg:
select t.date, d.date_as_string from table1 t cross apply dbo.format_date(t.date,'yyyy-mm-dd') d