From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.devel Subject: Re: Can `format-time-string' produce full/extended ISO 8601 times? Date: Thu, 6 Aug 2009 14:39:20 -0400 Message-ID: References: <878wi1epta.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1249583982 1100 80.91.229.12 (6 Aug 2009 18:39:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Aug 2009 18:39:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 06 20:39:35 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MZ7sD-0003UI-K7 for ged-emacs-devel@m.gmane.org; Thu, 06 Aug 2009 20:39:33 +0200 Original-Received: from localhost ([127.0.0.1]:52497 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MZ7sD-0002bY-0S for ged-emacs-devel@m.gmane.org; Thu, 06 Aug 2009 14:39:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MZ7s8-0002bT-Ae for emacs-devel@gnu.org; Thu, 06 Aug 2009 14:39:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MZ7s2-0002b6-R5 for emacs-devel@gnu.org; Thu, 06 Aug 2009 14:39:26 -0400 Original-Received: from [199.232.76.173] (port=33901 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MZ7s2-0002b3-KY for emacs-devel@gnu.org; Thu, 06 Aug 2009 14:39:22 -0400 Original-Received: from mail-yx0-f172.google.com ([209.85.210.172]:43697) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MZ7s2-0000Fv-80 for emacs-devel@gnu.org; Thu, 06 Aug 2009 14:39:22 -0400 Original-Received: by yxe2 with SMTP id 2so1368252yxe.14 for ; Thu, 06 Aug 2009 11:39:21 -0700 (PDT) Original-Received: by 10.151.112.17 with SMTP id p17mr575971ybm.150.1249583960975; Thu, 06 Aug 2009 11:39:20 -0700 (PDT) In-Reply-To: <878wi1epta.fsf@mail.jurta.org> X-Google-Sender-Auth: 635bc272a967f27d X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:113754 Archived-At: 2009/8/2 Juri Linkov : >> Does `format-time-string' produce full/extended ISO 8601 format times? > > Do you complain that `format-time-string' uses the extended format for > date/time and the basic format for time zone? Well, RFC 3339 says: Wasn't a complaint at all. FTMP `format-time-string' does _exactly_ what one would expect. To reiterate, the gist of my query is this: Is it possible to format the UTC offset/ZONE with a colon per the 'Extended format? >From what I am able to gather the "%z" of the `format-time-string' spec doesn't produce a colon delimited UTC-offset/ZONE and provides only for production of the time-numoffset as: +/-time-hourtime-minute -> +/- hhmm -> "-0500" To the extent that the standard is unclear/ambiguous, stating that: 'For example, to produce full ISO 8601 format, use "%Y-%m-%dT%T%z".' can not be correct as there is no 'full ISO 8601' format; e.g. the following is not 'full' but only full-ish :) (format-time-string "%Y-%m-%dT%T%z") => "2009-08-06T13:50:23-0400" ; On a w32 system. This would _appear_ to stand in contrast the referenced section of the standard, e.g. '4.2.5.1-2 of ISO 8601:2004(E)' which permits at least two other possible variations: The 'Basic format' is one of these: +/-time-hour -> +/-hh -> "-05" +/-time-hourtime-minute -> +/- hhmm -> "-0500" With the later variant of the basic format considered _more_ specific than the former. My specific concern is w/re to the standards proviso for an extended format such that: +/-time-hour:time-minute -> +/- hh:mm -> "-05:00" > > Due to ambiguities in ISO 8601, some interpretations had to > be made. First, ISO 8601 is not clear if mixtures of basic and > extended format are permissible. > > And provides a grammar that permits mixtures: > > time-numoffset = ("+" / "-") time-hour [[":"] time-minute] > As you point out, _here_ the standard is ambiguous as to canonical preference and permissible deviations. That said - as I read the standard - it would seem that when in doubt the Extended (and where applicable delimited) format is generally considered _more_ preferable than the Basic. Regardless, apropos my initial query, whether this particular reading is correct need not be of concern. Rather, I remain curious to know if it is _possible_ to produce a time string with a UTC/ZONE portion having the format: +/-time-hour:time-minute -> +/- hh:mm -> "-05:00" ; _with_ colon delimiter Specifically, I am inquiring whether such production is possible with the current existing `format-time-string' (sans extension). If so, this should be be made clear in the docs. If not, the docs should be modified to indicate: 'For example, to produce an ISO 8601 compliant format, use "%Y-%m-%dT%T%z".' as contrasted with the current: 'For example, to produce full ISO 8601 format, use "%Y-%m-%dT%T%z".' Further, if a production of UTZ/Zone colon delimited timestring is not possible and it does not pose significant runtime/source overhead I would propose consideration for inclusion of an additional "%Z" format spec to `format-time-string'. > Juri Linkov s_P