Date Format?
-----Original Message----- From: es4-discuss-bounces at mozilla.org [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Garrett Smith Sent: 4. mars 2008 07:45 To: es4-discuss Discuss Subject: Date Format?
Will ES4 have a simple date formatter?
If you're asking for something that takes a format string and produces a date according to that format then no.
What is the recommended approach?
Thank you,
Garrett
Garrett Smith wrote:
Will ES4 have a simple date formatter?
Es4-discuss mailing list Es4-discuss at mozilla.org, mail.mozilla.org/listinfo/es4-discuss
strftime would be uber.
Date.prototype.toLocaleFormat(format) in SpiderMonkey provides access exactly to strftime functionality.
, Igor
On Tue, 2008-04-01 at 00:39 +0200, Igor Bukanov wrote:
Date.prototype.toLocaleFormat(format) in SpiderMonkey provides access exactly to strftime functionality.
As with prior discussion regarding PTC, being "in SpiderMonkey" is relatively useless to those of us programming for the web.
Cheers,
-- Nathan de Vries
2008/3/31 Nathan de Vries <nathan at atnan.com>:
On Tue, 2008-04-01 at 00:39 +0200, Igor Bukanov wrote:
Date.prototype.toLocaleFormat(format) in SpiderMonkey provides access exactly to strftime functionality.
As with prior discussion regarding PTC, being "in SpiderMonkey" is relatively useless to those of us programming for the web.
Firefox uses SpiderMonkey.
On Mon, 2008-03-31 at 16:56 -0700, Garrett Smith wrote:
Firefox uses SpiderMonkey.
I don't get what you mean. Firefox is part of the web, but it's not the web.
Without being part of a standard such as ES4, Mozilla's implementation of Date.prototype.toLocaleFormat() is just yet another Javascript feature you've got to be careful about using, and will typically get wrapped in a Yet Another Library (like noSuchMethod et al).
Cheers,
-- Nathan de Vries
Second that notion.
On Tue, Apr 1, 2008 at 1:36 AM, Robert Sayre <sayrer at gmail.com> wrote:
2008/3/31 Nathan de Vries <nathan at atnan.com>:
Without being part of a standard such as ES4...
It is a library problem. The ES4 language spec is not the place to fix every standard library deficiency.
That's funny. Even if it's missing the point.
One benefit of having a standard formatter would be expected standard result. I've seen quite a few date formatters that assume the whole world speaks English. Korea likes having their dates formatted in Korean. Similarly for Japanese, and Spanish.
Keeping property-objects of key-value pairs for each language seems to be considerably large overhead.
Here's English:-
months : {
full : ["January", "February", "March", "April", "May",
"June", "July", "August" , "September", "October", "November", "December"],
abbr : ["Jan", "Feb", "Mar", "Apr", "May", "Jun",
"Jul", "Aug", "Sep", "Oct", "Nov", "Dec"]
},
One strategy is to (1) make a file for each locale. CalendarLocale_en.js. This can be seen in the DynArch DHTML Calendar. This is more efficient than (2) cramming every locale in one file. leaving non-localized strings in the main file is never a good option.
Either way, it requires translating date components manually, for each language. I don't speak Korean, and if nobody in my company does, then what, hire a translator?
The other approach (and a fairly common one), is (3) to assume that English is the only language. This fails to fulfill the use case of localized date formatting.
Properly formatting dates, solution (1), in ES is a lot of work.
Is there a way to add Date Formatting to ES4 without adding too much bloat to the language? What's the least ES4 could do? How much would that cost, in terms of "bloat" to the language?
What I'm not getting from this group is the answer to solve the problem of formatting dates. Lets not turn a blind eye to the problem.
Garrett
-----Original Message----- From: es4-discuss-bounces at mozilla.org [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Garrett Smith Sent: 17. april 2008 14:16 To: Robert Sayre Cc: es4-discuss Subject: Re: Date Format?
On Tue, Apr 1, 2008 at 1:36 AM, Robert Sayre <sayrer at gmail.com> wrote:
2008/3/31 Nathan de Vries <nathan at atnan.com>:
Without being part of a standard such as ES4...
It is a library problem. The ES4 language spec is not the place to fix every standard library deficiency.
That's funny. Even if it's missing the point.
One benefit of having a standard formatter would be expected standard result. I've seen quite a few date formatters that assume the whole world speaks English. Korea likes having their dates formatted in Korean. Similarly for Japanese, and Spanish.
Keeping property-objects of key-value pairs for each language seems to be considerably large overhead.
Here's English:-
months : { full : ["January", "February", "March", "April","May", "June", "July", "August" , "September", "October", "November", "December"],
abbr : ["Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"] },One strategy is to (1) make a file for each locale. CalendarLocale_en.js. This can be seen in the DynArch DHTML Calendar. This is more efficient than (2) cramming every locale in one file. leaving non-localized strings in the main file is never a good option.
Either way, it requires translating date components manually, for each language. I don't speak Korean, and if nobody in my company does, then what, hire a translator?
The other approach (and a fairly common one), is (3) to assume that English is the only language. This fails to fulfill the use case of localized date formatting.
Properly formatting dates, solution (1), in ES is a lot of work.
Is there a way to add Date Formatting to ES4 without adding too much bloat to the language? What's the least ES4 could do? How much would that cost, in terms of "bloat" to the language?
What I'm not getting from this group is the answer to solve the problem of formatting dates. Lets not turn a blind eye to the problem.
Alright then. "No."
Garrett wrote:
Properly formatting dates, solution (1), in ES is a lot of work.
Indeed it is. A couple of Javascript toolkits have taken a crack at this problem and provide pluggable, reusable solutions you may want to look at (e.g. Dojo's dojo.date.format and datejs available from Google code) There are several facets to this problem. First there is the parsing and formatting logic, basically string and regexp operations which are not unreasonable to delegate to a toolkit. Another is maintaining the large translation tables needed to provide this function (communities like the one in unicode.org/cldr have taken this on in open source -- there's no reason why you should have to build your own translations). Then there is the mechanism to embed and load the appropriate resources. Note that this is essentially a package loading problem which is not unique to Dates, and Dojo leverages its package loader to load locale-sensitive information like these date formats. I think this part is most challenging to provide in Javascript, but appears to be outside the scope of ES4.
The current ES4 Date proposal provides unambiguous ISO formats which should encourage better programming practices. That seems like the right place to start. Hard-coding mm/dd/yyyy is just as bad as hard-coding English strings.
2008/4/17 Adam Peller <apeller at us.ibm.com>:
Garrett wrote:
Properly formatting dates, solution (1), in ES is a lot of work.
Indeed it is.
I can see you've invested considerable time and effort into this problem.
A couple of Javascript toolkits have taken a crack at this problem and provide pluggable, reusable solutions you may want to look at (e.g. Dojo's dojo.date.format and datejs available from Google code) There are several facets to this problem. First there is the parsing and formatting logic, basically string and regexp operations which are not unreasonable to delegate to a toolkit. Another is maintaining the large translation tables needed to provide this function (communities like the one in unicode.org/cldr have taken this on in open source -- there's no reason why you should have to build your own translations).
Where'd dojo get the CLDR conversion to JSON?
Then there is the mechanism to embed and load the appropriate resources. Note that this is essentially a package loading problem which is not unique to Dates, and Dojo leverages its package loader to load locale-sensitive information like these date formats. I think this part is most challenging to provide in Javascript, but appears to be outside the scope of ES4.
Why not just use a script tag to load the only the correct locale from the start by checking Accept-Language?
<script src="DateLocale<%= getLocaleSuffix() %>"></script>
I don't encourage scriptlets; a tag would be better. Just saying for example.
Dojo's date locale requires an object called 'dojo' and a lot of static methods of that object. Extensively. A project that's already using dojo could leverage that, but compared to a native strftime, it's some overhead to get that date formatted.
The current ES4 Date proposal provides unambiguous ISO formats which should encourage better programming practices. That seems like the right place to start. Hard-coding mm/dd/yyyy is just as bad as hard-coding English strings.
It's a choice, though, and there's plenty of live code on the web that does that. Not to PIck on Orbitz (cheap tix), but calendar.clickDate.toSource() they may have other formats that get picked in the server side code.
Garrett
Will ES4 have a simple date formatter?