Independent Date and Time objects/ISO Dates
On 5/15/07, mkaply <mozilla at kaply.com> wrote:
In my work with microformats, I'm finding that the Date object is not very useful for representing a date without a time. Has any thought been given to having separate Date and Time objects?
Some minor discussion last year but nothing serious. The Date object represents a time stamp in milliseconds relative to a known time, so really represents both date and time. Why is this not adequate?
In addition, has any thought been giving to allowing the construction of Date objects using ISO dates or allowing Date objects to output as ISO Dates.
A subset of ISO date format has been incorporated into the proposed revision, with a requirement that Date.parse must be able to parse it and Date.toISOString must generate it.
On 15/05/07, mkaply <mozilla at kaply.com> wrote:
In addition, has any thought been giving to allowing the construction of Date objects using ISO dates or allowing Date objects to output as ISO Dates.
The output part is already available in SpiderMokey through d.toLocaleFormat("%Y-%m-%d") where d is an instance of Date as there toLocaleFormat is effectively a wrapper around strftime. Perhaps instead of inventing Date.toSomeParticularDateFormat and corresponding Date.parseSomeParticularFormat ES4 should just provide functionality available in C via strftime / strptime?
, Igor
Lars T Hansen-2 wrote:
Some minor discussion last year but nothing serious. The Date object represents a time stamp in milliseconds relative to a known time, so really represents both date and time. Why is this not adequate?
An ISO date does not need to contain a time. So how would an ISO only date be parsed into a Date object and then output as the same date only item? Right now if you give JS a date, it assumes a time. You need to be able to pass in a date with no time, have it stored as a date only with no time and then retrieve it as a date. ToLocaleString for instance on a date only should produce just a date with no time.
On 5/15/07, mkaply <mozilla at kaply.com> wrote:
Lars T Hansen-2 wrote:
Some minor discussion last year but nothing serious. The Date object represents a time stamp in milliseconds relative to a known time, so really represents both date and time. Why is this not adequate?
An ISO date does not need to contain a time. So how would an ISO only date be parsed into a Date object and then output as the same date only item? Right now if you give JS a date, it assumes a time. You need to be able to pass in a date with no time, have it stored as a date only with no time and then retrieve it as a date. ToLocaleString for instance on a date only should produce just a date with no time.
Ah. No, we've not talked about doing that, and you don't get to set a bit on the Date object that says "the time does not matter". I suppose you could, but I don't (yet) know what the consequences are. For backwards compatibility a date string probably needs to yield a Date object with a time. For ISO strings we could conceivably do something different, but I'm not sure about that.
On May 16, 2007, at 10:37 AM, Lars T Hansen wrote:
Ah. No, we've not talked about doing that, and you don't get to set a bit on the Date object that says "the time does not matter". I suppose you could, but I don't (yet) know what the consequences are. For backwards compatibility a date string probably needs to yield a Date object with a time. For ISO strings we could conceivably do something different, but I'm not sure about that.
We're talking about this thread in the TG1 meeting now. It would help
us to see how you've worked around Date to meet your use-cases. We
think a few lines of JS can force a fit, but we're interested to see
what you did. We don't plan to add a strftime-like API, but if we're
right about the few-lines scale of adaptation, that might fit in a
standard method or two.
On 5/23/07, Brendan Eich <brendan at mozilla.org> wrote:
On May 16, 2007, at 10:37 AM, Lars T Hansen wrote:
Ah. No, we've not talked about doing that, and you don't get to set a bit on the Date object that says "the time does not matter". I suppose you could, but I don't (yet) know what the consequences are. For backwards compatibility a date string probably needs to yield a Date object with a time. For ISO strings we could conceivably do something different, but I'm not sure about that.
We're talking about this thread in the TG1 meeting now. It would help us to see how you've worked around Date to meet your use-cases. We think a few lines of JS can force a fit, but we're interested to see what you did. We don't plan to add a strftime-like API, but if we're right about the few-lines scale of adaptation, that might fit in a standard method or two.
Part of the problem is that Date.parse does not yield a Date object, but a timestamp, so retaining information about what was and wasn't part of the time stamp requires a new parsing API.
IMO we should not take the Date class further than we've taken it. Given the regularity of the ISO date format, it's reasonably convenient to subclass Date and add parsers/serializer; JSON clients can override toJSONString or even toISOString. And so on.
In my work with microformats, I'm finding that the Date object is not very useful for representing a date without a time. Has any thought been given to having separate Date and Time objects?
In addition, has any thought been giving to allowing the construction of Date objects using ISO dates or allowing Date objects to output as ISO Dates.
Thank you.
Mike Kaply