Re: [9front] Re: Date and time handling.

[ori@eigenstate.org]

Thanks for the review. Good questions and comments!

> ori@eigenstate.org writes:
> 
>>                 vlong    abs; /* milliseconds since Jan 1 1970, GMT */
> 
> Do you really mean "GMT" or "UTC"?

I mean /adm/timezone/GMT. If we renamed it to UTC or TAI, I'd be happy
with that too. Also, bug in comment: should be seconds.

>>                 int sec; /* seconds (range 0..59) */
>>                 int min; /* minutes (0..59) */
>>                 int hour;     /* hours (0..23) */
>>                 int mday;     /* day of the month (1..31) */
>>                 int mon; /* month of the year (0..11) */
> 
> The "sec" field should probably be 0..60, to allow for leap seconds.
> Why do you specify the month as 0..11, rather than 1..12?

Agreed. I'll change the comment for sec, though right now I
dont' think our timezone files know how to represent leap seconds.

Some fields are (IMO, unexpectedly) 0 based because this is intended to
be merged with  struct Tm eventaully. That means keeping the unfortunate
definitions compatible.
 
>>                 int tzoff;    /* time   zone delta from GMT */
> 
> Is the value in tzoff specified in seconds?  Does a negative value mean
> east or west of GMT?

Seconds, west is negative, as in /adm/timezone/*

>>           Time zones are represented as strings.  They can be provided
>>           as the abbreviated timezone name, the full timezone name,
>>           the path to a timezone file, or an absolute offset in the
>>           HHMM form.
> 
> Is that HHMM allowed to have a leading +/- sign?

Not yet implemented, but that'd make sense.
 
>>           Tmtime converts the millisecond-resolution timestamp 'abs'
>>           into a Tm struct in the requested timezone.
> 
> If abs has millisecond resolution, and secs resolution of one second,
> then where in struct Tm do the fractional seconds go?
>

abs :)

But for now, I've changed resolution to seconds. I'd be willing to change
it to anything else.

>>           6,2006
>>                The year in 2 and 4 digit forms, respectively.
> 
> (2006 - 1900) != 6

Yep, but that's how Go specifies it. Anyways, I've completely changed
the formatting. Now we have YY, YYYY for those two formats.
 
>>           ISO-8601,RFC-3339 and RFC-2822 dates.
> 
> It would also be nice to support ISO-8601 without the "T" separator
> between the date and time, which looks ugly and confuses people who
> haven't read the standard.  I often use a space or "@" sign for improved
> readability, even though it's technically not ISO.

Another change: I'm making the time parsing explicit. I think that the list
of reasonable formats cam vary by caller, and if it turns out that it's
duplicated a lot, we can revisit this decision easily.

>>           Tmfmt formats a Tm struct according to the format fmt. If
>>           fmt is nil, we format as in ctime(2). At most nbuf-1 char-
>>           actters are written into buf, which is nul-terminated.
> 
> Does that (nbuf-1) count include the terminating NUL?

No. I think I've rephrased this in the manpage already -- and, actually,
just moved to format strings entirely. Now, you'd do something like:

	snprint(buf, sizeof(buf), "%τ", tmfmt(&tm, "YYYY MMM DD hh:mm:ss");

> 
>>            if(a.abs == b.abs)
>>                 print("same0);
>>            else
>>                 print("different0);
> 
> These are missing closing quotation marks.
> 
> Also, how does the library handle dates prior to the Gregorian
> Reformation?

This library only deals with proleptic gregorian time. Which is
jargon for "Get bent".

> It's nice to have input on a man page before it gets printed and bound.
> :) Thanks!

It's nice to avoid making easy mistakes.