* Re: [9front] date -t vs rfc3339 i which is correct:
@ 2019-12-10 19:17 cinap_lenrek
2019-12-10 19:34 ` ori
0 siblings, 1 reply; 3+ messages in thread
From: cinap_lenrek @ 2019-12-10 19:17 UTC (permalink / raw)
To: 9front
my interpretation is that this rfc3339 is a SUBSET of iso-8601 and we
hit edge case in iso-8601 that is outside of rfc3339. we'r correct
for iso 8601 but not for rfc3339. i think this should be changed
so we cover both specifications and make date -t more widely usefull.
--- a/sys/src/cmd/date.c Mon Dec 09 18:08:02 2019 +0100
+++ b/sys/src/cmd/date.c Tue Dec 10 20:15:42 2019 +0100
@@ -15,7 +15,7 @@
char*
isodate(Tm *t)
{
- static char c[25]; /* leave room to append isotime */
+ static char c[26]; /* leave room to append isotime */
snprint(c, 11, "%04d-%02d-%02d",
t->year + 1900, t->mon + 1, t->mday);
return c;
@@ -39,7 +39,7 @@
c[9] = '-';
tz = -tz;
}
- snprint(c+10, 5, "%02d%02d", tz / 60, tz % 60);
+ snprint(c+10, 6, "%02d:%02d", tz / 60, tz % 60);
} else {
c[9] = 'Z';
c[10] = 0;
--
cinap
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [9front] date -t vs rfc3339 i which is correct:
2019-12-10 19:17 [9front] date -t vs rfc3339 i which is correct: cinap_lenrek
@ 2019-12-10 19:34 ` ori
2019-12-10 19:48 ` Stanley Lieber
0 siblings, 1 reply; 3+ messages in thread
From: ori @ 2019-12-10 19:34 UTC (permalink / raw)
To: cinap_lenrek, 9front
> my interpretation is that this rfc3339 is a SUBSET of iso-8601 and we
> hit edge case in iso-8601 that is outside of rfc3339. we'r correct
> for iso 8601 but not for rfc3339. i think this should be changed
> so we cover both specifications and make date -t more widely usefull.
>
> --- a/sys/src/cmd/date.c Mon Dec 09 18:08:02 2019 +0100
> +++ b/sys/src/cmd/date.c Tue Dec 10 20:15:42 2019 +0100
> @@ -15,7 +15,7 @@
> char*
> isodate(Tm *t)
> {
> - static char c[25]; /* leave room to append isotime */
> + static char c[26]; /* leave room to append isotime */
> snprint(c, 11, "%04d-%02d-%02d",
> t->year + 1900, t->mon + 1, t->mday);
> return c;
> @@ -39,7 +39,7 @@
> c[9] = '-';
> tz = -tz;
> }
> - snprint(c+10, 5, "%02d%02d", tz / 60, tz % 60);
> + snprint(c+10, 6, "%02d:%02d", tz / 60, tz % 60);
> } else {
> c[9] = 'Z';
> c[10] = 0;
>
> --
> cinap
The change looks good to me, but one question:
Is there anything that uses the output of 'date -t' and cares?
(How did we run into this?)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [9front] date -t vs rfc3339 i which is correct:
2019-12-10 19:34 ` ori
@ 2019-12-10 19:48 ` Stanley Lieber
0 siblings, 0 replies; 3+ messages in thread
From: Stanley Lieber @ 2019-12-10 19:48 UTC (permalink / raw)
To: 9front
i don’t recall what the original need was.
werc’s blagh app generates an atom feed, which needs rfc3339 dates, and an rss feed, which needs rfc2822 dates. 9front’s date -m is good for rfc2822.
but since werc is targeted at the lowest common denominator p9p, i implemented 9front date -m and -t as rc functions in werclib.rc. i noticed the rfc3339 vs iso-8601 discrepancy when atom.tpl still failed to validate atom feeds. so, werclib.rc/^fn ndate now has flags -a for rfc3339, -t for iso-8601, and -m for rfc2822. i kept -t for now (it’s just an echo statement) in case somebody needs it later.
sl
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-12-10 19:48 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-10 19:17 [9front] date -t vs rfc3339 i which is correct: cinap_lenrek
2019-12-10 19:34 ` ori
2019-12-10 19:48 ` Stanley Lieber
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).