Re: [ANN] Penlight 1.3 Request for Comment

[Andrew Starks <andrew.starks@...>]

On Saturday, September 14, 2013, steve donovan  wrote:
> Since the otherwise excellent luadate seems to have become
> unmaintained, the idea is to get a robust package that does what it
> does well, and works for people who have to deal with DST.
>
> steve d.
>
> [1] https://github.com/stevedonovan/Penlight
> [2] http://stevedonovan.github.io/Penlight
> [3] https://github.com/stevedonovan/Penlight/blob/master/CHANGES.md
> [4] https://github.com/stevedonovan/Penlight/blob/master/lua/pl/Date.lua

Allow me to share some use cases:

I'm working with media timing and scheduling. Therefore, I have a large number of arbitrary clocks. These clocks can have independent frequencies and/or epochs. 

Examples:

    current time in nano time

    Given a frame count, return the nano time. 

    For playlistA, Make a clock that counts in frames, where zero is the schedules start time. 

     Given a value for playlistA, return the current time in nano time. 

So my library does all of this, (plus drop frame conversion). However, it does not return do so for dates, beyond the host clock. It can only work in number of samples since epoch. Wall clock time and date must always be given in terms of os.date (I hack % HOST_TICKS in there). 

It would be wonderful if there were a clock library which allowed me to make a date/time object with an arbitrary TICKS and EPOCH value, where epoch was some date/time value in the native clock's terms. 

That is, assuming the native clock is seconds:

My_ticks   =  1001/30000 (note that my library uses real numbers, so I'd need to deal with this, assuming that its ridiculous to provide a fractional tick.  Think samples/scale)

My_epoch = 1234567890.56789 -- os.time value where this clock is 0

Given the above, a call such as `my_clock.date(91011121314/30000)` would return the ISO UTC time/date, using the correct ticks and epoch. 

On ISO 8601: so long as you are providing a "day of week" function, this is the ONLY format that I would ever want and the only one that I would ever need you to parse. The only addition that I would ask for is for the support of arbitrary precision, after the decimal point. My opinion is that all other "vanity" date formats are a pain and can easily be derived by those in need. If you felt you HAD to provide it, do it in a sub-module. Call it something demeaning like, "mangle_date" :)

On parsing: I believe that the majority of your target users would be fine with LPEG as a dependency. I'm sure that this is not universally true, however it is "true enough" that you may consider providing your parser in LPEG variants. The benefit being compose-ability. You can provide the elements of the parser and I can re-order, extend, combine with my applications.... You get the idea. 

Note that in the original LuaDate object, time was internally divided between day and day part. This made it possible to deal in nano time, without resorting to 64 bit ints. Even with 64bit ints, the future is pretty limited, without shifting os.date's epoch. You might consider retaining that approach?

I'd be happy to contribute my clock library. However, it not only retains real numbers (fractions) through all conversions, it also has the int64 package as a dependency. Also, I would guess that it's too specialized for PL. 

I'll cut this email off at the time/date topic. But I must send one more. Maybe 2. :)

-Andrew