I like it. Here's a summary.
A datetime has three representations:
- (real) number of milliseconds since the epoch,
- string in some standard format (e.g. ISO 8601),
- plain old object with the following properties: year, month (one-based), day, hour, minute, second (real), zone, week, weekday.
Then there are four functions for generating datetimes and converting among the representations:
- Date.now() -> Number
- Date.object(Number | String, zone info? ...) -> Object
- Date.string(Number | Object, format and/or zone info? ...) -> String
- Date.number(Object | String, format and/or zone info? ...) -> Number
You'd need the tz database under the hood and maybe exceptions for impossible or ambiguous datetimes.
Aside from bundling the tz database, I don't see this library needing to be very large. And if it's small, it's not a big deal if it isn't standard.
I like it. Here's a summary.
A datetime has three representations:
- (real) number of milliseconds since the epoch,
- string in some standard format (e.g. ISO 8601),
- plain old object with the following properties: year, month (one-based), day, hour, minute, second (real), zone, week, weekday.
Then there are four functions for generating datetimes and converting among the representations:
- Date.now() -> Number
- Date.object(Number | String, zone info? ...) -> Object
- Date.string(Number | Object, format and/or zone info? ...) -> String
- Date.number(Object | String, format and/or zone info? ...) -> Number
You'd need the tz database under the hood and maybe exceptions for impossible or ambiguous datetimes.
Aside from bundling the tz database, I don't see this library needing to be very large. And if it's small, it's not a big deal if it isn't standard.