From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mimir.eigenstate.org ([206.124.132.107]) by ewsd; Sun Apr 12 20:36:20 EDT 2020 Received: from abbatoir.fios-router.home (pool-162-83-132-245.nycmny.fios.verizon.net [162.83.132.245]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id ec896bee (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO); Sun, 12 Apr 2020 17:36:05 -0700 (PDT) Message-ID: To: magma698hfsp273p9f@icebubble.org, 9front@9front.org Subject: Re: [9front] Re: Date and time handling. Date: Sun, 12 Apr 2020 17:36:04 -0700 From: ori@eigenstate.org In-Reply-To: <86k12kh85h.fsf@cmarib.ramside> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: ACPI method standard-oriented software-based framework 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.