Date.format proposal

[Devin]

So, let's face it: Formatting JavaScript Date's isn't fun.

I hereby propose we agree on a format method such as the one Steven
Levithan has already cooked up <http://stevenlevithan.com/assets/misc/
date.format.js>.

[Adam Peller]

Aside from the ISO part, which is already going into ECMAScript 5, why would you need to standardize on this?  I'd propose we leave user presentation of Dates to toolkits, and this one is a fine choice for many users.

-Adam

[Kris Kowal]

On Tue, Jul 28, 2009 at 3:02 PM, Adam Peller<pel...@gmail.com> wrote:
> Aside from the ISO part, which is already going into ECMAScript 5, why would
> you need to standardize on this?  I'd propose we leave user presentation of
> Dates to toolkits, and this one is a fine choice for many users.
>
> -Adam

Before we could decide on this, I think we would need to make clear
our policy on modifications to primordial objects like Date in
implementations. I proposed to the Narwhal folks that we would keep a
policy of only modifying primordial objects during the bootstrapping
process (never in modules loaded by the program), and that we would
only do so in order to upgrade the material we had to either an ES5 or
a ServerJS standard. We would never augment globals in such a way
that they could introduce an incompatibility with a future standard.

Kris Kowal

[Kevin Dangoor]

On Tue, Jul 28, 2009 at 6:50 PM, Kris Kowal <cowber...@gmail.com> wrote:

Before we could decide on this, I think we would need to make clear
our policy on modifications to primordial objects like Date in
implementations.  I proposed to the Narwhal folks that we would keep a
policy of only modifying primordial objects during the bootstrapping
process (never in modules loaded by the program), and that we would
only do so in order to upgrade the material we had to either an ES5 or
a ServerJS standard.  We would never augment globals in such a way
that they could introduce an incompatibility with a future standard.

Yeah, I think this is a reasonable policy. It's certainly fine to provide functions in a module and people could on their own or via third party package augment primordials  with those functions.

Kevin

--
Kevin Dangoor

work: http://labs.mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com

[Mark Porter]

No disagreement about modifying primordials.

I do think that there should be something like a DateUtil module. JS's standard date handling is just too primitive for real work. Creating a date handling library is something that every implementer has to do. A ServerJS standard that can co-exist with a host implementation would seem ideal.

Here is Myna's implementation, which was shamelessly stolen from the EXTjs project (and they borrowed heavily from PHP):

Docs: http://www.mynajs.org/shared/docs/js/libOO/files/Date-js.html
Code: http://code.google.com/p/myna/source/browse/trunk/1.0/web/shared/js/libOO/Date.js

I'm not suggesting we use the Myna implementation (It modifies Date for one thing), but just for feature ideas.

If one of the goals of ServerJS is to create a common base for implementing server-side JavaScript, then date manipulation should be part of it.

[Adam Peller]

On Wed, Jul 29, 2009 at 10:00 AM, Mark Porter <dm4...@gmail.com> wrote:

No disagreement about modifying primordials.

And none here.  I wasn't concerned with where to hang the code, but whether serverjs wants to do this at all.
 

I do think that there should be something like a DateUtil module. JS's standard date handling is just too primitive for real work. Creating a date handling library is something that every implementer has to do.

Every implementer does not need to do this.  One can choose from many open source date formatting implementations.  We've already seen two on this thread, and more are listed in the wiki.  ECMAScript made a deliberate choice not to enhance the lacking host date formatting in core and felt the problem was beyond the scope of the language.  It's being solved in JavaScript by toolkits in levels of detail.  Getting the i18n tables right is non trivial, and some date libraries go through great lengths to provide this sort of support.  Similarly, time zones are complex, but some folks are tackling that problem using the Olson database (e.g. fleegix)

A ServerJS standard that can co-exist with a host implementation would seem ideal. [snip] If one of the goals of ServerJS is to create a common base for implementing server-side JavaScript, then date manipulation should be part of it.

 
What are the boundaries of what serverjs needs to standardize?  Why does serverjs need to get in the toolkit business or rubber stamp one date formatting API as standard?  Why not provide only what needs to be available to bootstrap a common JS platform, at which point existing serverjs-compliant toolkits can be leveraged?  The portability problem is already solved by serverjs.  Is there something in the current serverjs proposal which requires (non-ISO) date formatting?

[Ash Berlin]

On 29 Jul 2009, at 16:52, Adam Peller wrote:

On Wed, Jul 29, 2009 at 10:00 AM, Mark Porter <dm4...@gmail.com> wrote:

No disagreement about modifying primordials.

And none here.  I wasn't concerned with where to hang the code, but whether serverjs wants to do this at all.
 

I do think that there should be something like a DateUtil module. JS's standard date handling is just too primitive for real work. Creating a date handling library is something that every implementer has to do.

Every implementer does not need to do this.  One can choose from many open source date formatting implementations.  We've already seen two on this thread, and more are listed in the wiki.  ECMAScript made a deliberate choice not to enhance the lacking host date formatting in core and felt the problem was beyond the scope of the language.  It's being solved in JavaScript by toolkits in levels of detail.  Getting the i18n tables right is non trivial, and some date libraries go through great lengths to provide this sort of support.  Similarly, time zones are complex, but some folks are tackling that problem using the Olson database (e.g. fleegix)

Date formatting is only part of the problem with dates. The others being time zones and date math: particularly when dealing with working out intervals across timezones/sumertime changes. If anyone fancies a read: http://search.cpan.org/~drolsky/DateTime-0.50/lib/DateTime.pm#How_Datetime_Math_is_Done

A ServerJS standard that can co-exist with a host implementation would seem ideal. [snip] If one of the goals of ServerJS is to create a common base for implementing server-side JavaScript, then date manipulation should be part of it.

 
What are the boundaries of what serverjs needs to standardize?  Why does serverjs need to get in the toolkit business or rubber stamp one date formatting API as standard?  Why not provide only what needs to be available to bootstrap a common JS platform, at which point existing serverjs-compliant toolkits can be leveraged?  The portability problem is already solved by serverjs.  Is there something in the current serverjs proposal which requires (non-ISO) date formatting?

I keep going back and forth on this point, between the "ServerJS only needs to bootstrap" to the "But having useful modules in core is good" (to combat perl's pervasive TIMTOWDTI culture which is troublesome at times.) 

Also for added fun on date formatting: formatting a Date object to the right to pass of to a database, which of course they all expect different ones.

[Kris Kowal]

On Wed, Jul 29, 2009 at 8:52 AM, Adam Peller<pel...@gmail.com> wrote:
> On Wed, Jul 29, 2009 at 10:00 AM, Mark Porter <dm4...@gmail.com> wrote:
>>
>> No disagreement about modifying primordials.
>
> And none here.  I wasn't concerned with where to hang the code, but whether
> serverjs wants to do this at all.

Ah, seems like there's interest! May I recommend that someone take
responsibility for the secretarial affairs for Date related features
and begin a section on the Wiki?

Kris

[Mike Samuel]

I wrote most of the date arithmetic, parsing, and formatting code for
google calendar in JS. I can probably dig up something if that would
be helpful.

The approach I took differed a bit from java libraries in a few
respects
(1) Date parsing did not return a date object. It returned a partial
date and a confidence so that we could infer missing fields based on a
reference date and type hints. This worked in a large number of
locales and handled things like Chinese numerals that I think java has
trouble with.
(2) We differentiated between dates and approximate date-times
(accurate to the minute) and date-times accurate to the ms. Dates and
approx date-times were represented as bitpacked numbers so that common
operations like incrementing to the next date could be done
efficiently with a mask & test and an increment in the 80+% case with
no object creation overhead.
(3) Timezone handling was done using a VTIMEZONE which uses recurrence
rules to calculate the daylight/standard switchover times.

Some of this is available as benchmark fodder:
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/demos/calendar/time-cajita.js
http://code.google.com/p/google-caja/source/browse/trunk/tests/com/google/caja/demos/calendar/time_test.js

http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/demos/calendar/rrule-cajita.js
http://code.google.com/p/google-caja/source/browse/trunk/tests/com/google/caja/demos/calendar/rrule_test.js

On Jul 29, 10:29 am, Kris Kowal <cowbertvon...@gmail.com> wrote:
> On Wed, Jul 29, 2009 at 8:52 AM, Adam Peller<pel...@gmail.com> wrote:

[Adam Peller]

"wants" was probably the wrong word.  What's the mission of serverjs?  What is the point where the project should say "Javascript can do that without our help, that's best left to a separate project"?  To me, this really seems like one of those things.

However, if this is taken on, avoiding the Date object altogether for internal representation could be a good choice, for many reasons -- performance, various API ambiguities with leap years, time zones and such.

-Adam

[Kevin Dangoor]

Working with dates and times is pretty fundamental. I don't think we'd want libraries to be speaking a different language with respect to dates and times.

Kevin

[Kris Kowal]

On Wed, Jul 29, 2009 at 11:46 AM, Mike Samuel<mikes...@gmail.com> wrote:
>
> Some of this is available as benchmark fodder:
>  http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/demos/calendar/time-cajita.js
>  http://code.google.com/p/google-caja/source/browse/trunk/tests/com/google/caja/demos/calendar/time_test.js
>
>  http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/demos/calendar/rrule-cajita.js
>  http://code.google.com/p/google-caja/source/browse/trunk/tests/com/google/caja/demos/calendar/rrule_test.js
>

These are great, and shouldn't take much effort to port. I'll see
what I can do with them.

Kris

[George Moschovitis]

> Working with dates and times is pretty fundamental. I don't think we'd want
> libraries to be speaking a different language with respect to dates and
> times.

+1

A standard API for date formatting/arithmetic should be part of
ServerJS.

-g.

--
http://blog.gmosx.com

[Adam Peller]

Perhaps a distinction could be made between "core" serverjs -- API which is *required* to bootstrap a platform and provide native methods like I/O and network, versus "standard library" sorts of APIs where you could just rely on some pure js toolkit (running on the portable core) but want to try to form a standard?  This might help define the project goals help to mitigate some of the risk of taking on additional work (where does it end?)

[Mike Wilson]

Just throwing in some contrast to the PHP inspired
stuff mentioned so far; people from a posix background
may be more used to the date pattern formats used by
strftime():
- strftime http://se2.php.net/strftime
- "php" http://se2.php.net/manual/en/function.date.php

Best regards
Mike Wilson

Devin wrote:
> I hereby propose we agree on a format method such as
> the one Steven Levithan has already cooked up
> http://stevenlevithan.com/assets/misc/date.format.js

[Christoph Dorn]

> Just throwing in some contrast to the PHP inspired
> stuff mentioned so far; people from a posix background
> may be more used to the date pattern formats used by
> strftime():
> - strftime http://se2.php.net/strftime
> - "php" http://se2.php.net/manual/en/function.date.php
>

As further inspiration this recently released book [1] may be of help. I
have not read it myself.

Christoph

[1] - http://www.phparch.com/books/isbn/9780981034508

[Mike Samuel]

I looked a bit at this proposal.

I have a few criticisms.
(1) For client side javascript, it usually makes sense to assume the
user's locale for operations like date formatting, but for server side
javascript it doesn't, and this has no mention of locale. It does
separate out some locale sensitive strings (though not AM/PM) so you
could switch locales by mucking with global state, but that means a
given global context can only be used for a single locale at a time.
No chance of doing a mail-merge where different recipients receive
mail each in their own preferred locale.

(2) If instead of providing a formatter like date*pattern->string, you
provide pattern->date->string, then you can optimize common cases and
improve performance on short patterns, and you can use javascript
closures to memoize any information you have to look up based on the
pattern string a la
function makeFormatter(pattern, locale) {
if (pattern == /* very simple but common pattern */) { return /*
hand optimized code */; }

// exract info from pattern string here. month name lists if
necessary, etc.
// extracted info lasts only as long as the formatter is
reachable.

return function (date) {
// date specific code here.
};
}

(3) Sometimes what you really want to format is a pair of dates, and
pattern strings deal with that badly.
For example, you often want to format a range of dates that do not
overlap a month boundary like
11-15 July, 2009
2009年07月11-15日
11.-15. Juli, 2009
despues once hasta quince de julio de 2009
but use a longer form for dates that split over 2 months. So having
your format function able to take ranges as a primitive might help.

RFC2445 defines a useful set of primitives that can be formatted:
dates (can also handle months, years, quarters, semesters)
instants
date ranges
(e.g. 3 months, 4 days, and 2 hours)

All these primitives can be treated as a series of integer fields.
And in all these cases, you can find a mapping from locales to format
strings which contain literal portions and dynamic portions which map
from integer field values into arrays of localized strings, or to a
(offset, modulus, min-digit-count) triplet.

It can be very useful to be able to map an unknown field when
formatting to a locale specific string like '?' with appropriate
padding. That way, you can use the same formatting scheme to present
partial information to the user. For example "I couldn't understand
the date you entered: 1 ???, 2009. Please select a month."

[Kris Kowal]

On Mon, Aug 3, 2009 at 2:41 PM, Mike Samuel<mikes...@gmail.com> wrote:
> I looked a bit at this proposal.
> I have a few criticisms.

Thanks for articulating these thoughts. There are a lot of excellent
points here.

Your caja-time and caja-rrule modules are in my Narwhal branch
"calendar" as the "calendar" and "calendar/rrule" respectively. I
encourage anyone to take a look at them.

http://github.com/kriskowal/narwhal/blob/calendar/lib/calendar.js
http://github.com/kriskowal/narwhal/blob/calendar/lib/calendar/rrule.js

The calendar tests mostly pass:
http://github.com/kriskowal/narwhal/blob/calendar/tests/calendar/rrule.js

+ Running testParseIcal
Assertion Failed in testParseIcal: AssertionError: -43268096
Expected equal = "20061125"
Actual = -43268096
Passed 20; Failed 1; Error 0;

The rrule tests don't fare as well:
http://github.com/kriskowal/narwhal/blob/calendar/tests/calendar/rrule.js
Passed 4; Failed 68; Error 0;

I am a little concerned that these types are too optimized for the
calendar case to be useful as date/time moments generally since they
do not have second or sub-second resolution.

Kris Kowal