On Tue, 27 Nov 2001, Brandon Wiley wrote: > > Give me just one example of where it would be significantly more > > difficult to "compute" with the old style versus the new style... > > Today is January 1st, 2003. You want yesterday's entry. With the new > format, no matter what day of what month of what year it is, you subtract > 86400 from today's entry and you get yesterday's entry. With the old > format you must first subtract one from the day (1). You then check for > month rollover. In this case it happens. So you now decrement the month > (1). Then you check for year rollover. In this case it happens. So you > decrement the year (2003). So now you know it's December, 2002. Next you > need to find the day of the month. If the month is not February then you > look up which month it is in a table to see how many days that month has. > If it is February then you compute the number of days in the month based > on the year. In this case it's December so you look up December in the > table and get 31. So you set the date to December 31, 2002. > > Whatever aesthetic or usage concerns you may have, you must admit that > this is more difficult to compute than subtracting 86400. > Amen, brother!
> I think they probably need to have the format explained to them and > perhaps whatever tools the use should be extended to do what they want > them to do with less hassle. Whether or not it's easy to generate a DBR by > hand, tools should exist to do it for you. Although it would be nice to be > easy to generate by hand. I think that could be accomplished by having the > format in decimal rather than hex. That way the site authors can break out > a calculator instead of a calendar and type DBR-numdays*86400. > I agree that the only reasonable alternative to the hex dates is decimal dates, but inconsistency in a standard is going to trip someone up. Of course the only reason I have against doing metadata completely in decimal is that it was hex, and many implementations will be broken by a change to decimal. 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/3c93e735/attachment.pgp>
