344360 - XPCOM needs Date/Time Interface

Status: RESOLVED INCOMPLETE

(Core :: XPCOM, enhancement)

Description

[Robert Sayre]

I need something like this to return for the date fields in the feed parser (used from C++ and JS). I have no preference for a particular solution, as long as there is one. 

AllPeers has hit a similar issue, and has an interface.

Comment 1

[Benjamin Smedberg]

You want an interface instead of a typedef for PRTime?

Comment 2

[Benjamin Smedberg]

We already have a PRTime typedef, see http://lxr.mozilla.org/mozilla/source/xpcom/base/nsrootidl.idl#67

Comment 3

[Robert Sayre]

AllPeers has the following, to which I would add a TZ field. Maybe PRTime would be good enough here... maybe not.

include "nsISupports.idl"

/**
 * XPCOM implementation of date/time.
 */
[scriptable, uuid(8C71D218-54A7-496e-B3C0-B6E8361C92A4)]
interface apIDateTime : nsISupports
{
	readonly attribute long long time;
	readonly attribute long microseconds;
	readonly attribute octet seconds;
	readonly attribute octet minutes;
	readonly attribute octet hours;
	readonly attribute octet mday;
	readonly attribute octet month;
	readonly attribute short year;
	readonly attribute octet wday;

	/**
	* Initialize from a PRTime value.
	*
	* @param time
	*      Number of microseconds since the beginning of the NSPR epoch
	*      (midnight January 1st, 1970 UTC)
	*/
	void init(in long long time);

	/**
	* Converts the date to a string in ISO 8601 format.
	*
	* @return
	*      ISO 8601 string representation of the date.
	*/
	ACString toString();

	/**
	* Create a new date from the string.
	*
	* @param
	*      ISO 8601-formatted string representation of the date to parse.
	*/
	void buildFromString(in ACString str);

    /**
     * Creates RFC 822 date and time string format, see
     * http://www.faqs.org/rfcs/rfc822.html, 
     * section 5., "DATE AND TIME SPECIFICATION"
     */
    ACString toRFC822String();
};

Comment 4

[Matthew Gertner]

I wouldn't add a TZ field. It's probably better to use UTC everywhere internally and do TZ conversion when necessary (e.g. for display). Unless you see a reason why the internal representation needs to be TZ adjusted.

Comment 5

[Matthew Gertner]

Attachment: Implementation of apIDateTime

Here's our implementation. IIRC, the main motivation for doing this was to enable use of variants that contain dates. Of course, we could have just stored the time as a 64-bit integer, but then there is no way to determine that the variant contains a date. By doing it this way, we can check for the apIDateTime interface.

Also useful for the same reasons that nsISupportsString, etc. are useful.

Comment 6

[Matthew Gertner]

That said, I honestly can't remember why we didn't decide to use nsISupportsPRTime. Perhaps because the code to do simple things like get the month or whatever was significantly more verbose. The right solution might be simply to add the attributes that we have in apIDateTime to nsISupportsPRTime.

Comment 7

[Robert Sayre]

(In reply to comment #4)
> I wouldn't add a TZ field. It's probably better to use UTC everywhere
> internally and do TZ conversion when necessary (e.g. for display). Unless you
> see a reason why the internal representation needs to be TZ adjusted.
> 

I need to round-trip feed dates, which can have offsets.

Comment 8

[Matthew Gertner]

Okay, that makes sense.