On Tue, 27 Nov 2001, Ian Clarke wrote: > On Tue, Nov 27, 2001 at 10:44:55AM -0600, thelema wrote: > > I disagree with you about the relative complexity of the two formats, > > but anyway. > > Well, reality is on my side, just look at the fact that CofE, probably > one of the most sophisticated freesite authors, has opted not to support > forward/backwards links. > I agree that it's unfortunate and a problem that he(?)'s not supporting them. > > The main reason the change was made is because everything else is hex. > > Usability should never take second place to a purely asthetic > consideration. > > > Also, time in seconds since the epoch is as good a time system as any, > > Not if you talk to freesite authors, many are furious that we have made > life more difficult for them for no good reason. > > > having the very nice advantage over the "readable" dates of being much > > easier to compute with. > > Give me just one example of where it would be significantly more > difficult to "compute" with the old style versus the new style... > Okay, what date is 86400 seconds after 19981231000000? If you want to say 19990101000000, you're wrong.
> > One could even have a > > pre-processor that changes <TOMORROW> to tomorrow's date and <YESTERDAY> > > to yesterday's date in hex. > > What about 2 days ago, 5 days ago etc... > fine, <TODAY+n> or <TODAY-n> (of course n has to be in hex. :) > > I don't have any problems with changing it to the seconds-since-epoch in > > decimal (if adding 86400 is easier than adding 0x15180), but the old > > date format was a pile, especially with having the increment being in > > seconds. > > How many complaints did we receive from freesite authors about the old > mechanism? How many did we receive about the new mechanism? I rest my > case. > > Ian. > I agree that it's easier for client authors to just change one number in their documents to represent tomorrow and yesterday, but dates being as crazy as they are, I'd much prefer not to have any real date handling code in that part of freenet. I think that the right place to put it anyway is in a pre-processor that handles the <TODAY+n> macros. or even better one that just handles <FUTURE+n> and <PAST-n> macros, so that when people use non-86400 second update times everything is automatically handled. Thelema -- E-mail: thelema314 at bigfoot.com If you love something, set it free. GPG 1536g/B9C5D1F7 fpr:075A A3F7 F70B 1397 345D A67E 70AA 820B A806 F95D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20011127/75aa55c8/attachment.pgp>
