Re: proposal: add basic time type to the standard library
[Guido]
... Another thing to consider is that for most apps, the choice of the date/time format should be taken out of the hands of the programmer and placed into the hands of the user, through some kind of preference setting. I18n and L10n also strongly suggests to take this route.
I'm sure nobody wants to admit this <wink>, but in sheer numbers, nobody has more experience with this stuff than Microsoft. If you sit at your Windows box and go to Start -> Settings -> Control Panel -> Regional Settings, you'll get a tabbed dialog for specifying the format of number, currency, time, and date displays. A Windows app that ignores the settings here is considered to be broken (and rightly so). Idiosyncratic formats for user-visible number/currency/date/time info is going to become an increasingly Bad Idea on other OSes too.
Idiosyncratic formats for user-visible number/currency/date/time info is going to become an increasingly Bad Idea on other OSes too.
Oh, so it'll be at least another 10 years before the same wisdom reaches the typical web application... :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
[Tim]
Idiosyncratic formats for user-visible number/currency/date/time info is going to become an increasingly Bad Idea on other OSes too.
[Guido]
Oh, so it'll be at least another 10 years before the same wisdom reaches the typical web application... :-)
Optimist.
"TP" == Tim Peters <tim@zope.com> writes:
TP> [Guido] >> ... Another thing to consider is that for most apps, the >> choice of the date/time format should be taken out of the hands >> of the programmer and placed into the hands of the user, >> through some kind of preference setting. I18n and L10n also >> strongly suggests to take this route. TP> I'm sure nobody wants to admit this <wink>, but in sheer TP> numbers, nobody has more experience with this stuff than TP> Microsoft. If you sit at your Windows box and go to Start -> TP> Settings -> Control Panel -> Regional Settings, you'll get a TP> tabbed dialog for specifying the format of number, currency, TP> time, and date displays. A Windows app that ignores the TP> settings here is considered to be broken (and rightly so). TP> Idiosyncratic formats for user-visible TP> number/currency/date/time info is going to become an TP> increasingly Bad Idea on other OSes too. I've not been following this thread at all, so apologies if this has been brought up already. The localization context should not (always) be taken from the user environment. In systems like web-based services, the context will instead be relative to the person/entity making the remote request, so we have to be able to explicitly specify the localization context, or at least query, modify, and restore some global context. -Barry
I've not been following this thread at all, so apologies if this has been brought up already.
No, but unclear if it's relevant.
The localization context should not (always) be taken from the user environment. In systems like web-based services, the context will instead be relative to the person/entity making the remote request, so we have to be able to explicitly specify the localization context, or at least query, modify, and restore some global context.
Sure. So the interface may be different. The main argument (that you shouldn't be using t.year() to format dates) remains the same. --Guido van Rossum (home page: http://www.python.org/~guido/)
"GvR" == Guido van Rossum <guido@python.org> writes:
>> The localization context should not (always) be taken from the >> user environment. In systems like web-based services, the >> context will instead be relative to the person/entity making >> the remote request, so we have to be able to explicitly specify >> the localization context, or at least query, modify, and >> restore some global context. GvR> Sure. So the interface may be different. The main argument GvR> (that you shouldn't be using t.year() to format dates) GvR> remains the same. Doesn't Java have separate formatting objects? You decide which format object you need based on the localication context, then you pass in the timestamp/date/money/whatever thingie and the format object knowws how to render that data representation in the appropriate localization. makes-sense-to-me-ly y'rs, -Barry
Doesn't Java have separate formatting objects? You decide which format object you need based on the localication context, then you pass in the timestamp/date/money/whatever thingie and the format object knowws how to render that data representation in the appropriate localization.
Yes, that's probably a good way to do it in general. There may be global functions that are initialized based on getenv(), and Zope may provide a different set of global functions that are initialized based on the preferences of the client. --Guido van Rossum (home page: http://www.python.org/~guido/)
On 26 Feb 2002 at 17:48, Barry A. Warsaw wrote:
Doesn't Java have separate formatting objects? You decide which format object you need based on the localication context, then you pass in the timestamp/date/money/whatever thingie and the format object knowws how to render that data representation in the appropriate localization.
Yeah. In an optimization gig I had a couple years ago, I had them take out their use of the fancy format objects. It took 7,000 calls to print a date time according to the trace. -- Gordon http://www.mcmillan-inc.com/
[Barry]
I've not been following this thread at all, so apologies if this has been brought up already.
The localization context should not (always) be taken from the user environment. In systems like web-based services, the context will instead be relative to the person/entity making the remote request, so we have to be able to explicitly specify the localization context, or at least query, modify, and restore some global context.
Like I said <wink>, Microsoft has more experience with this stuff than anyone. Check out http://www.trigeminal.com/ Provided you're using IE, it should up come in the right language for you. Try viewing it in different languages, and note, e.g., how date formats change automatically. Here's an article on how they do it: http://msdn.microsoft.com/msdnmag/issues/0700/localize/localize.asp
Tim Peters wrote:
Like I said <wink>, Microsoft has more experience with this stuff than anyone. Check out
Provided you're using IE, it should up come in the right language for you. Try viewing it in different languages, and note, e.g., how date formats change automatically.
Except that: Dernière mise-à-jour: 02/08/02 05:33 AM is not correct. The AM/PM distinction is one which no right-thinking folks bother with. Then again, it looks like that particular line is not using their fancy logic, since the date is in the future if you follow the pattern set by other dates. Also note: Des problemes avec ce site? SVP, contacter le webmaster avec vos commentaires, questions ou suggestions (si possible, en anglais). which is pretty funny =). --david
[David Ascher]
Except that:
Dernière mise-à-jour: 02/08/02 05:33 AM
is not correct.
Well, if you're not viewing the page in English like God intended, you should be grateful it talked back to you at all.
... Also note:
Des problemes avec ce site? SVP, contacter le webmaster avec vos commentaires, questions ou suggestions (si possible, en anglais).
which is pretty funny =).
Mabye to you. Me, I don't know French at all, so I'm delighted to see them produce French that I can understand easily. Hell, I even recognize SVP as a suffix of the good old English RSVP -- it figures the French would drop the first and most important letter <wink>. the-kind-of-i18n-a-sensitive-american-can-support-ly y'rs - tim
David Ascher wrote;
Also note:
Des problemes avec ce site? SVP, contacter le webmaster avec vos commentaires, questions ou suggestions (si possible, en anglais).
which is pretty funny =).
Tim Peters wrote:
Mabye to you. Me, I don't know French at all, so I'm delighted to see them produce French that I can understand easily.
In case the humour wasn't clear, here's the translation: Problems with this site? Please contact the webmaster with your comments, questions, or suggestions (if possible, in English). -- ?!ng
[Ping]
In case the humour wasn't clear, here's the translation:
Problems with this site? Please contact the webmaster with your comments, questions, or suggestions (if possible, in English).
Yes, it was clear. If the French could get over their speech impediment of using "avec" when they mean "with", and stuck to webspeak in this style, they *would* be speaking English. I think that's even funnier <wink>.
Tim Peters <tim@zope.com>:
Hell, I even recognize SVP as a suffix of the good old English RSVP -- it figures the French would drop the first and most important letter <wink>.
RSVP = repondez s'il vous plait = reply, please SVP = s'il vous plait = please (I know, this has nothing to do with timezones. Sorry. I'll stop now.) Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
David Ascher <DavidA@ActiveState.com>:
Des problemes avec ce site? SVP, contacter le webmaster avec vos commentaires, questions ou suggestions (si possible, en anglais).
which is pretty funny =).
Obviously they haven't yet implemented the natural-language- understanding webmaster-bot that adapts to the user's language settings. They could just pipe your query through Babelfish, though... Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
Tim Peters:
Like I said <wink>, Microsoft has more experience with this stuff than anyone. Check out
Provided you're using IE, it should up come in the right language for you. Try viewing it in different languages, and note, e.g., how date formats change automatically.
Well, it crushes us Aussies under the jackboot of US cultural imperialism, unless month 31 was recently added to the calendar. This is despite sending a nice Accept-Language: en-au It does work if I change to German. Neil
Tim> .... If you sit at your Windows box and go to Start -> Settings -> Tim> Control Panel -> Regional Settings, you'll get a tabbed dialog for Tim> specifying the format of number, currency, time, and date displays. I'm gonna go ever so slightly out on a limb here and make a wild-ass guess here that Apple probably had this functionality before Microsoft and that like on Windows, all well-behaved Mac applications had to use the user's settings. Maybe this abstract time object's strftime method (or time.strftime) should grow format specifiers for the user-specified date and time... Tim> Idiosyncratic formats for user-visible number/currency/date/time Tim> info is going to become an increasingly Bad Idea on other OSes too. Of course, neither Apple's nor Microsoft's efforts in this area will help the poor person trying to emit a dynamic web page containing "correctly" formatted dates. You still have to guess or just fall back to something most everyone can deduce. can-we-squeeze-it-into-http-2.0?-ly, y'rs, Skip
[Skip Montanaro]
... Of course, neither Apple's nor Microsoft's efforts in this area will help the poor person trying to emit a dynamic web page containing "correctly" formatted dates. You still have to guess or just fall back to something most everyone can deduce.
No, MS languages support APIs for high-level things like FormatCurrency(), and some have dedicated Currency, Time and Date types. You don't *get* low-level control under these things, and the high-level APIs automatically respect user preferences. So, for example, if you're generating dynamic content via a VBScript program, it's easy provided you stick to VBScript's high-level date format functions when you pump out a date: you can't not respect the user's date format preferences then. See the links I posted just before this to see how a server can suck down the user's preferences, at least to a first approximation (the default formats for the user's primary language).
participants (9)
-
barry＠zope.com -
David Ascher -
Gordon McMillan -
Greg Ewing -
Guido van Rossum -
Ka-Ping Yee -
Neil Hodgson -
Skip Montanaro -
Tim Peters