<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
David Bruehlmeier wrote:
<blockquote
cite="midmailman.1.1101329987.19178.typo3-dev@lists.netfielders.de"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">(ADOdb date library)</pre>
</blockquote>
<pre wrap=""><!---->
Sorry for that! It was by no means meant to offend you. To be honest, I have
not spent much time investigating the ADOdb suggestion, since I figured it
would
a) need an external library to interpret an internal data type and
b) doesn't use an international standard which I think would be a good
practice for a totally new data type.
</pre>
</blockquote>
I think inventing a whole new dateconcept is very wrong, and would make
integration very difficult.<br>
<br>
The widely recognized alternative to the current unix time format is to
use a signed 64 bit integer instead of the current 32 bit. This covers
back some twenty times the age of the universe, and, well, the same
(minus 30 years ;) ) ahead. 64 bit ought to be enough for anybody. <br>
<br>
The most obvious advantage is the direct backwards compatibiality. Drop
a 32 bit date in the 64 bit field, and everything behaves the way you
want it to. Sorting works out of the box.<br>
<br>
As a bonus, while covering a much wider range than the proposed format,
it is only half the size (64 vs. 17*8 = 136). Also, when 64 bit
computers prevail over the next few years, sorting and seraching on the
field will be faster. <br>
<br>
To answer your concerns:<br>
a) To use the proposed format, some functionality would have to be
added to the TYPO3 core anyway. In the spirit of opensource
development, why not just grab the relevant functions from ADOdb and
throw them in?<br>
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8">
<title>Requirements for non-UNIX dates</title>
<meta name="GENERATOR" content="OpenOffice.org 1.1.2 (Linux)">
<meta name="AUTHOR" content="Kasper Skårhøj">
<meta name="CREATED" content="20021101;320000">
<meta name="CHANGED" content="20041119;16093600">
<meta name="Email" content="typo3@bruehlmeier.com">
<meta name="Author" content="David Bruehlmeier">
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8">
<title>Requirements for non-UNIX dates</title>
<meta name="GENERATOR" content="OpenOffice.org 1.1.2 (Linux)">
<meta name="AUTHOR" content="Kasper Skårhøj">
<meta name="CREATED" content="20021101;320000">
<meta name="CHANGED" content="20041119;16093600">
<meta name="Email" content="typo3@bruehlmeier.com">
<meta name="Author" content="David Bruehlmeier">
b) The proposed adjustments to ISO8601 will break the standard anyway.
And using 64 bits instead of 32 bits certainly is an as much of a
standard as we need: <a class="moz-txt-link-freetext" href="http://www.gnu.org/software/year2000.html">http://www.gnu.org/software/year2000.html</a> <br>
<br>
<pre class="moz-signature" cols="72">Venlig hilsen
Martin Seebach
</pre>
</body>
</html>