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
