Currently Being ModeratedJan 17, 2012 12:10 PM (in response to Frank Caggiano)
Thank you, Frank, that is perfect, just what I was looking for - now I don't have to reimplement the "Numerical Recepies in C"
Usually I use the Smile companion osax (http://www.satimage.fr/software/en/downloads/index.html), there are many numerical functions, but those are not part of the Apple Script standard distribution.
Have you ever noticed this strange behaviour of the Apple Script Editor? My Date&Time preferences are set to US (Computer), but still the AppleScript Editor replaces any Date String I enter immediately by a german date string. I wonder, if I ever wil be able to deploy my script with english date formatting.
For example: "1/11900 12:00:00" will be replaced immediately by "Montag, 1. Januar 1900 12:00:00"
(* Standard reference dates: Epoch and Bessel Year *)
global J2000date, J1900date, B1950date, B1982date -- date objects
global J2000, J1900 -- Julian date constants
set J1900date to (date "Montag, 1. Januar 1900 12:00:00") - 1 * days
-- Julian year J1900,1900 Jan 0.5 TT
set J1900 to 2415020
set J2000date to date "Samstag, 1. Januar 2000 12:00:00"
-- Julian year J2000,2000 Jan 1.5 TT
set J2000 to 24151545
set B1950date to (date "Sonntag, 1. Januar 1950 00:00:00") + 0.923 * days
-- Besselian year 1950
Currently Being ModeratedJan 17, 2012 12:41 PM (in response to léonie)
Frank, I'm still trying to understand what kind of Timezone information you will need:
The biggest gotcha is the lack of the ability to get TZ info on an image.
If you only need the Timezone to compute this equation:
then the scripting addition "time to GMT" should suffice to get the capture time in UTC - assuming my observations above are correct, and Aperture really exports the capture dates correctly transformed to the current timezone setting of the system.
For the DeltaT_GMT in the equation above is not the offset of the official timezone of the country, it is the offset of the Local Time (LT) and depends solely on the longitude of the location. To take the political timezone of a country may introduce mistakes by several hours. So we do not need the timezone settings associated with the images, we need the the capture date in a representation where we know the correct timezone associated with the date, and we need the longitude of the location, and I think (hope) you have both.