No on the timezone deletion. While I support the ISO Date and 24 hour clock, doing away with timezones adds confusion and accomplishes little.
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.
How would that help? Timezones help to coordinate hours with day and night. If you know something happended somewhere at 3a.m. you can assume it was night (unless it was a polar day). Without timezones the task becomes much more difficult.
I don't know. I think that we're at a point where knowing the absolute time is more important to knowing the relative time (relative to daylight).
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".
I disagree. If I make an appointment for a meeting I'm flying to, 5 timezones away, it's better to be able to say 'let's meet at 9am' rather than having to look up what time '2 hours after getting out of bed' is in that particular location. Similarly, if I read news about Japan that says 'an explosion occurred at 10pm' I prefer to know that that means 'after the regular working day' instead of having to look up when the working day ends there.
Maybe the ideal solution would involve specifying all times in two timezones (local and GMT), side-by-side? Practically, I'm now interested in adding something like a <time> HTML tag that would let users decide how they want to see it, and see it in their own localtime automatically. JQuery plugin anyone?
There was a useful (I found) discussion about no timezones on here a few days ago, when discussing Samoa's decision to switch to the other side of the date line - http://news.ycombinator.com/item?id=2528338
Exactly. With international communication on the rise, it's best (IMHO) to do away with the timezone concept, and just use one time format everywhere.
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.
Consider also that there is one hour per year which does not exist and one hour per year which happens twice (at-least within the context of local time if you live in an area with daylight savings)
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.
Times should really be given as Miami Internet Beats[1], since it's compatible with everyone in US Eastern and doesn't have antiquated concepts like "hours," or "minutes."
Charles Stross does that in his novel Glasshouse: durations are described in kiloseconds, megaseconds, and gigaseconds. (100Ksec is just under 28 hours -- a reasonable proxy for a day -- and 1 Gsec is about 31 years.) In a space-faring society, with no standard astronomical day or year, it made sense.
In all three systems, it is both written and spoken year-month-day, which was the point.
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.
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).
I'm British, I've worked with a large number of clients' SQL Server installs. I think I've only twice seem yyyy-dd-mm as a default behaviour, yyyy-mm-dd was far more common.
I've only seen it assume yyyy-dd-mm when the user's locale is set to "English (British)". In most instances I've come across this setting is just left at the default ("English", which implies "English (American)") even if everything else in the stack is localised for the UK, so the oddity isn't noticed. My build instructions now explicitly state that "English (British)" should not be used due to the way it affects how dates in strings are interpreted when the format NNNN-NN-NN is seen.
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 have a formatDate() function lying around somewhere, but I cannot create functions or views on many of the DBs. convert(varchar(8), @myDate, 112) seems a daft way to go about things - and I have been wondering if I have been doing something wrong...
Agreed. The CONVERT syntax is rubbish, but the output is so much more powerful. I'd rather have an equivalent of Date.ToString("YYYY-mmm-DD hh:mi:ss.ssss") in SQL but, sadly.... It could be written as a UDF but I'm not sure performance would be up to production use.
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.
It could be written as a UDF but I'm not sure performance would be up to production use.
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
