Thanks for the comments :)
The 'time' formats will be looked at definitely.
As for the timezone - I believe the RRP reports to us in EDT, so that's
what we use (coincidentally, we're in EDT as well...)
Charles Daminato
OpenSRS Support Manager
[EMAIL PROTECTED]
On Fri, 25 Aug 2000, Eric Cain wrote:
>
> Regarding the docs/:
>
> The docs are much better than the meager documentation found in the
> current public releases. This is exactly what many of us need;
> however, the protocol spec need less Perl and more spec. Ideally, the
> protocol spec would not have any references to Perl.
>
>
> Regarding dates and times:
>
> In the attributes hash returned as a result of an "Action Request"
> (action: REGISTER, GET, et al., object: DOMAIN), I notice, as it is
> in the current release, that the last_access_time is in seconds since
> epoch and expiredate is a string of format: "YYYY-MM-DD HH:MM:SS"
> (I know I am not the first to point this out)
>
> Seconds since epoch would be more convenient since it doesn't have to
> be parsed. If some people must have this time as string for some
> reason, that's fine. But would it not be possible to provide the
> expiredate in seconds since epoch as well?
>
>
> Another problem with the expiredate is that it is ambiguous since it
> is provided in Eastern time.
> As you may know, daylight savings ends 02:00:00 in the morning. The
> date is most ambiguous around 2000-10-29 01:30:00 when it could be in
> daylight savings time or standard time. This is true because neither
> a time zone is associated with it (EST, EDT, UTC, et al.) nor a time
> offset from UTC (-04, -05)
>
> Granted one should not take chances renewing an hour before the
> expiry of the domain but I intend to store this data locally in a
> database and want to have accurate data. One could figure out what
> the time would likely be based on the time the domain was registered
> but that does not address real problem which is the ambiguity.
> (having the time in seconds since epoch or a string in UTC time
> solves this problem)
>
>
> The OpenSRS API provides higher precision than whois does on dates
> and times. (expiredate for example) Would it be possible to get the
> creation time and last updated time via the API as well? These seem
> to be the only relevant times that are missing which cannot be
> accessed via the API.
>
>
> Eric
>
