XPCOM needs Date/Time Interface

RESOLVED INCOMPLETE

Status

()

Core
XPCOM
--
enhancement
RESOLVED INCOMPLETE
11 years ago
5 years ago

People

(Reporter: Robert Sayre, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
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

11 years ago
You want an interface instead of a typedef for PRTime?

Comment 2

11 years ago
We already have a PRTime typedef, see http://lxr.mozilla.org/mozilla/source/xpcom/base/nsrootidl.idl#67
(Reporter)

Comment 3

11 years ago
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

11 years ago
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

11 years ago
Created attachment 228964 [details]
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

11 years ago
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.
(Reporter)

Comment 7

11 years ago
(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

11 years ago
Okay, that makes sense.

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.