Re: date.js in Lua?

[Alexander Gladysh <agladysh@...>]

On Tue, Mar 20, 2012 at 02:09, Miles Bader <miles@gnu.org> wrote:
> [Hmm, I guess this is a job for ... LPEG!]

Some personal notes on the library — if it is to be written anew; in
no particular order:

1. First of all, full specification for the input format is needed
(best to find existing one, otherwise take whatever date -d accepts
and write it in EBNF).

2. <redacted>

3. It should be possible to use the library in "strict mode". I.e. I
should be able to see if there is some additional garbage in the
string, and be able to report error to user.

4. A decent test suite, for good and bad input. Please do look at
other implementation's test suites for additional corner cases. Don't
forget leap years and seconds, weird time zones, negative epoch time
etc.

5. Would like to have i18n of some sort, but that's probably for 2.0.

6. Don't care for performance much.

7. Should work for LuaJIT 2 and latest LPEG on POSIX-systems. Don't
care much for Lua 5.2 and non-POSIX.

8. Would need a compatibility mode for date.js (unfortunately). That
is, library should support all (most?) notations that date.parse()
supports, and in compatibility mode should reject (in sense of "strict
mode" above) everything that date.parse() does not support. This may
be done with a separate aux module or something — I simply need to
validate whatever user wrote.

9. Would need a rockspec file for each release, plus scm rockspec.

10. Would need nice and full documentation.

11. Note on time zones: other implementations seem to explicitly
include some information on time zones. I don't think this is a good
idea. If you wouldn't access tzdata (or equivalent) for this
information, just limit hardcoded time zones to UTC/UT/GMT (I.e.
GMT+0).

12. If a tm-like structure is constructed in the process, it should be
possible to get it instead of epoch time.

13. Would be nice to be able to optionally infer some info from locale
-k LC_TIME equivalent (using luaposix, of course).

* * *

The problem is that I do not (yet!) have a "commercial" use-case for
such module except item 8 (which is the reason for my original
question, and could be done in a simpler way). So I can't sponsor
module development in full (and have no time to code it myself). But
it looks interesting and potentially useful, so maybe something could
be done...

If we'll have a complete specs for the library, maybe I would find
some way to contribute some man/hours by my team for the
implementation... If you have something to say, please contribute to
the design phase :-) All feedback welcome.

(If anyone knows something reusable, non-GPL, please share — it is
always preferable to reinventing the wheel.)

Alexander.