Benjamin Coates <coates at windmail.net> writes:
> it's public domain, so the licensing is a non-issue. The code will
> be trivial to port to any language that you can get a yacc/bison for
[...]
> it's actually quite simple; a 10-element grammar, a few tables, and
> a little math, so I don't think there will be a lot of trouble with
> inconsistent implementations.
Well this code has been around for several years now -- and still
every little tool that takes a date accepts a different subset of the
possible formats. A few versions back, CVS did not accept input in the
date format that it used for output. All this does not give me too
much hope.
Being public domain is fine, but it also means that everybody will
snarf a private copy for a project, maybe fix a few bugs, add another
format, etc.
> It will be nowhere near the most difficult task in writing
> an alternative freenet implementation.
Sure. But maybe additional tools need to understand that, too, for
example to parse a freesite page.
There is already much complexity (redirects, key types, asymmetry),
but each of these buys us significant features. The gain of being able
to say [3 months 2 days after Hirohito died] is small.
> One of the original complaints about YYYYMMDDHHMMSS is that calendar
> dates are difficult to work with and support, both to usefully parse
> and generate...
Yes, keeping just the seconds is much easier (whether in hex or
decimal is really irrelevant). But since people have a hard time
converting dates to seconds supporting this form is a win. You win
much less by also supporting [August 14] since people can easily
translate this to [20010814000000] in their heads.
> supporting them at all is much of the work, so we
> may as well support them in a robust fashion, and using
> already-available code to parse them in a consistent fashion without
> requiring everyone to write their own date parsing code should
> reduce the work required to do so.
If you want already-available code. Here you are for YYYYMMDDHHMMSS,
with nondigits ignored. Not that it was hard to write off the top of
my head:
----- C/C++:
/* return the numerical value of a decimal digit.
ASSUMPTIONS: c is an ASCII digit
*/
inline unsigned char digit(char c)
{
return c - '0';
}
/* takes the first DIGITS from *S, ignoring non-digits, and computes
their combined value. *S points after the last digits on exit.
*/
unsigned long number(char **s, size_t digits)
{
unsigned long a = 0;
while (digits && **s)
if (isdigit(**s)) {
a *= 10;
a += digit(**s);
(*s)++;
digits--;
}
return a;
}
/* takes an ISO-style date (YYYYMMDDHHMMSS) in ISO and returns seconds
since 1969 (UNIX time). All nondigits in ISO are ignored. */
time_t iso2unix(char *iso)
{
struct tm t;
t.tm_year = number(&iso, 4) - 1900;
t.tm_mon = number(&iso, 2) - 1;
t.tm_day = number(&iso, 2);
t.tm_hour = number(&iso, 2);
t.tm_min = number(&iso, 2);
t.tm_sec = number(&iso, 2);
return mktime(&t);
}
----- Perl:
use POSIX 'mktime';
sub iso2unix($)
{
local $_ = $_[0];
s/\D//g;
s/^(....)(..)(..)(..)(..)(..)//g or die "not enough digits";
return mktime($6,$5,$4,$3,$2 - 1,$1 - 1900);
}
ian at hawk.freenetproject.org (Ian Clarke) writes:
> It just annoys me when people try to fix something that isn't broken.
Applies here too.
--
Robbe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.ng
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20011205/547a2b41/attachment.pgp>
