i believe there's a problem with elisp's format-time-string.

in format-time-string, for example i have in my emacs init script:

(defun date-time () "insert current date-time string." (interactive)
(insert (format-time-string "%%Y-%%m-%%dT%%T%%z"))
)

when evaluated, i get:
2006-08-07T20:39:16-0700

the last 5 chars "-0700" is for time zone, corresponding to the %%z.

however, this does not seems to be a standard sec for time (RFC-3339),
which should have a colon after the 07. i.e. 2006-08-07T20:39:16-07:00

is there a way to generate the proper format using just
format-time-string without mucking with the string?

Xah
xah@xahlee.org
∑ http://xahlee.org/

In article <1155009669.061684.107400@p79g2000cwp.googlegroups.com>,
"xahlee@gmail.com" gmail.com> wrote:

It's the format used in RFC 2822 date/time strings, i.e. headers of
Internet email messages.

Thanks Barry for the answer.

I did some reading yesterday. RFC-3339 is a just a full-form and
stricter version of a particular syntax in ISO 8601.

Iso 8601 allows things like 2006, 200608, 2006-08-09T01:18:39-07:00, or
20060809T011839. Basically, the force behind the power of ISO8602 is to
dictate that year should be spelled out, and the order is
year-month-day, as oppose to the WASP's "month-day, year" and other
imperial moronicities.

Since ISO8601 allows a condensed form like "20060809T011839" thus
that's why in the time zone it also allows "-0700" instead of the more
proper "-07:00". RFC 3339, in its glory of verbosity of 4500 words,
came down to say that their format should be the ISO8601 form of:
yyyy-mm-ddThh:mm:ss±zz:zz

i modified my time stamp code to thus:

On 9 Aug 2006 01:59:29 -0700, "xahlee@gmail.com" gmail.com>
wrote:

1) Generate a unique identifier, including enough info, meaningful or
not, to guarantee uniqueness.

2) Run the unique identifier through a one-way hash function, such as
MD5 or SHA-1, thus obliterating the meaningfulness of any embeeded info.

Steve Schafer
Fenestra Technologies Corp
http://www.fenestra.com/

Great point!

I thought about this. The problem with this solution is that it
essentially ends up exactly as a random string, with added complexity
of the actual generation.

For example, if a hash function generates n chars. It is simpler, to
simply generate randomly n chars in the first place.

I guess what i wanted to say originally, was that, philosophically, to
generate a permanent universally unique number without any meaningful
info, it cannot avoid being a random string. In other words, the nature
of a universal unique number IS a random number of sufficient length.

in the process of writing these out, it seems obvious now. I think i'll
revisite my atom-id function to have it simply generate a long random
string. (with added colon etc so it is in the form of URI)

Xah
xah@xahlee.org
∑ http://xahlee.org/

Steve Schafer wrote:

Xah,

I feel the need to congratulate you. Recently, there was considerable
debate on these newsgroups regarding complaints to your ISP based on
the argument that your posts were largely spam/flame bait etc.

I will admit being one of the ones that thought your posts were
essentially spam designed to create flame wars and were usually
cross-posted to too many groups, many of which were inappropriate. I
didn't go so far as to formally complain to your ISP, but could
understand why some did recommend doing so.

I believe this most recent post is possibly the most appropriate and
reasonable post I've ever seen from you. You appear to have done your
research, your points are quite well argued/presented and I think you
raise some valid points that many would find interesting and useful,
particuarly in gnu.emacs.help. As a result, I observe you got a polite and
probably helpful suggestion from Barry. I for one can say that if you
can continue to post relevant and well reasoned/researched messages, I
would encourage you to continue participating in usernet discussions.

One of the issues I often had with your posts in the past was that
while you sometimes raised issues which were to some extent valid and
sometimes even justified, your proposed alternatives/solutions were...

On 9 Aug 2006 15:12:39 -0700, "xahlee@gmail.com" gmail.com>
wrote:

No, it's more than that. There is a stronger statistical likelihood of
uniqueness if the source data for the final result contains information
that is known to be unique (e.g., the MAC address of a NIC, such as is
used in the UUID generation algorithm).

Steve Schafer
Fenestra Technologies Corp
http://www.fenestra.com/

if your one-way function returns a 10 digit number, the probability of
it being unique is no better than a random 10-digit generating
function.

Xah
xah@xahlee.org
∑ http://xahlee.org/

On 17 Aug 2006 06:50:58 -0700, "Xah Lee" xahlee.org> wrote:

No, that's not true, precisely because the one-way hash is _not_ random.

To see this, consider UUIDs as a concrete example. A UUID is a
deterministically generated 128-bit number. Two machines are guaranteed
never to generate the same UUID because incorporated into the UUID is
the MAC address of (one of) the machine's NIC, which is a unique 48-bit
number.* Furthermore, a single machine is guaranteed never to generate
the same UUID because the current time is also incorporated into the
UUID.**

So, a UUID would serve perfectly as our universally unique identifier,
except for one thing: It contains human-decipherable information that
can be used for a variety of nefarious purposes.

Steve Schafer wrote:

There is a slightly deeper problem. Perfect one-way hash functions
from N bits to N bits cannot exist.

If every 128-bit number maps to exactly one other 128-bit number under
a hash function, then that hash function is reversible (ie, it is not
one-way). If there is some 128-bit number that more than one other
128-bit number maps to under a hash function, then that hash function
is not one-to-one (ie, it is not perfect). If there is some 128-bit
numer that no input hashes to under that function, then there must be
at least one other 128-bit number to which more than one input hashes
(pigeonhole principle).