Re: getting the date
Re: getting the date
- Subject: Re: getting the date
- From: Nigel Garvey <email@hidden>
- Date: Wed, 31 Dec 2003 11:36:59 +0000
Graff wrote on Tue, 30 Dec 2003 18:28:20 -0500:
>
On Dec 30, 2003, at 5:22 PM, Walter Ian Kaye wrote:
>
>> set theDate to (current date)
>
>> set {year:y, day:d} to theDate
>
>> copy theDate to b
>
>> set b's month to January
>
>>
>
>> text 3 thru 8 of ((y * 10000 + (b - 2500000 - theDate) div -2500000
>
>> *
>
>> 100 + d) as string)
>
>
>
> OK, I give. Can you please *explain* that 2500000 arithmetic?
>
> There has to be a science behind it...
>
The number that is built using this method is 20031230 so he makes that
>
into a string "20031230" and lops off the first 2 characters to get
>
"031230".
That's right. It looks delightfully eccentric, but it's based on the fact
that computers do sums a lot faster than they move chunks of text around.
At the slight cost of two additions and two multiplications, a situation
is created where only one number-to-string coercion takes place and the
result contains all the necessary zeros. Dealing with the year, month,
and day separately requires three coercions, plus two sets of
tests-and/or-concatenations for the leading zeros. In the current case,
where no separators are required, my approach has the added advantage of
needing no concatenations at all.
Graff on Tue, 30 Dec 2003 23:40:14 -0500:
>
>> ((b - theDate) div -2500000 + 1 )
>
>>
>
>> Which takes the difference (in seconds) between the current date and
>
>> and the the same day in January, divides that by 289 days (in
>
>> seconds) and adds a month. This gives you the current month,
>
>> roughly. This will probably work fine but I'd worry about it being
>
>> correct under all circumstances.
>
>
>
> OK, but then what makes 289 days so magical?
>
>
Sorry, my bad. I must have forgotten a decimal point, that should be
>
approximately 28.9 days. Approximately the average length of a month.
>
Basically the theory is ....
See my own reply to Walter's post.
>
It is a rough method but it does work. I would prefer to use a clearer
>
and more precise method but I can't argue with the results of this
>
script. If you want to convert a date quickly and you don't care if
>
people easily understand how it works then this script is for you.
It depends what people can easily understand, of course. :-) I personally
find all those Unix parameters pretty inpenetrable, though people who've
grown up with them seem to find them perfectly lucid. (I also find
palettes full of unnamed icons - like the Mac OS X Dock -virtually
useless, but many people find them preferable to learning to read.)
Although it's obviously good practice to make scripts as understandable
as possible, my basic philosophy is that it's the computer, not the
scripter, that has to execute the code. Anything that enables it to
complete a task with the minumum of faffing around is - in that sense -
better than something that's merely more easily understood by lazy
onlookers.
NG
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.