Can Applescript tell me which daynumber it is in relation to this year.
januari 3 = day 3 of the year, februari 1 = day 32 of the year and march 1 = day 60 (or 61!)
Hi,
I got this:
set cur_date to (current date)
set cur_year to (year of cur_date) as string
set first_day to (date (“1/1/” & cur_year))
set cur_day to (((cur_date - first_day) div days) + 1) – adding the first day
gl,
Hi,
I forgot about international date formats, so came up with this better one:
set cur_date to (current date)
set m to “january”
set first_day to date m
set cur_day to ((cur_date - first_day) div days) + 1
gl,
Thanks Kel,
But the first option is working perfectly.
Guess that OS X is more international than you think
Hi JB,
What I meant is that the other format uses the year/month/day format, so if month/day/year won’t work generally. Drank too much caffeine and can’t remember what was the best way to do this, but I think AppleScript can coerce “january” to date of the first day of the current year. If you’re just using your script for personal use in US, then both is ok.
gl,
Wel Applescript didn’ understand the term “january” in your second option.
I’m from the Netherlands, so the format we use is day/month/year.
But that’s no problem, cause I’m only interested in the total number of days to get the period number for administrative purposes. In our company, we’re working with 13 periods in a year.
The script gives not the current period, but the one before that, cause it’s for creating a bill. This bill is allways for work we’ve allready done ofcourse.
Here’s my result:
set cur_date to (current date)
set cur_year to (year of cur_date) as string
set first_day to (date ("1/1/" & cur_year))
set cur_day to (((cur_date - first_day) div days) + 1)
set cur_period to trunc (cur_day / 28) -- +1 for current period
do shell script "touch /Users/jbveenstra/Desktop/Testfactuurmap/Factuur_periode_" & cur_period & ".txt"
--here is some repeating code to create the content for the bill from a list of files allready processed
set ref_ to open for access ("Systeem1:Users:jbveenstra:Desktop:Testfactuurmap:Factuur_periode_" & cur_period & ".txt") with write permission
write FactRegel to ref_ starting at eof
close access ref_
Hi JB,
I learn something new every day. Didn’t know that anyone used day/month/year. Glad it worked out. Since you’re using unix stuff, there might be an easier way to get the day of the year, but I don’t know how.
gl,
A slightly more robust AppleScript solution based on Kel’s script would be something like:
[This script was automatically tagged for color coded syntax by Convert Script to Markup Code]
Which takes advantage of AppleScript’s constants for month names and calculates the difference between the two dates.
However, there is, indeed, a simple way to do this via shell scripting:
set dayNum to do shell script "date +%j"
which is fine if you’re in Mac OS X.
(also, Kel, the day/month/year format is far more common worldwide than the US’s month/day/year format. All of Europe, for example, uses day/month/year, as do many other countries.
Then, of course, there’s the ‘official’ ISO ‘International date format’ that uses ‘YYYY-MM-DD’ and is supposed to be unambiguous but try finding 2 Americians who know this 
)
Hi Camelot,
After all these years, I’ve been thinking that the year/month/day was standard in Europe since it’s the easiest to sort text. I guess easy is not required.
Have a good one,
More robust and about three times as fast, since the January date doesn’t have to be constructed from text “on the fly”.
Another, even simpler version would be:
set currentDate to (current date)
set Jan1Date to date "1/1/1"
set year of Jan1Date to year of currentDate
1 + (currentDate - Jan1Date) / days
No matter what nationality the system, ‘date “1/1/1”’ compiles as a date object representing 1st January 2001. After that, of course, it’s the date that counts, not the format in which you see it displayed in the script editor.
Dates like today’s make it easy on everyone: 9/9/04
Jon
Several solutions are proposed here. I liked the simplicity and speed of @Nigel Garvey’s solution the most, but I found some bugs.
The fact is that my data “1/1/1” is compiled not on January 1 of the current year, but on December 30 of the current year. In addition, it is compiled strictly into my localization, and this is not suitable for portability of the script to another localization. Also, at the end you need to subtract 1 day instead of adding:
I reworked the script taking into account the listed shortcomings:
on dayNumber() -- don't use this, it may return wrong result every 2 years
set currentDate to (current date)
set Jan1Date to (run script "date \"1/1/1\"")
set year of Jan1Date to (year of currentDate) - 1
return (currentDate - Jan1Date) div days - 1
end dayNumber
dayNumber()
Hm. I don’t like this confusion with 30 December (it may be 31 December as well) instead of 1 January.
Now, the solution from @Camelot has become the best (in terms of speed as well). I’ll probably still make myself a handler from it:
on dayNumber()
local currentDate, Jan1Date
set currentDate to (current date)
copy currentDate to Jan1Date
set month of Jan1Date to January
set day of Jan1Date to 1
return (currentDate - Jan1Date) div days + 1
end dayNumber
dayNumber()
Yes. The AppleScript behaviour’s changed in the nineteen years since that script was written.
Back in 2004, date “1/1/1” did compile as the 1st January 2001, much as date “01/01/01” does now. However, date “1/1/1” now attempts to compile as the 1st January 1. On my UK setup, I see date “Saturday, 1 January 1 at 00:00:00” after compilation, but getting the result’s weekday, day, month, year, and time properties returns {Saturday, 30, December, 0, 75}}. I gather from previous discussions on the subject here that the values you see depend on whereabouts in the world you are. Yvan in France reported getting property values which exactly matched the string values. Shane in Australia got something entirely different from either Yvan’s results or mine. It’s possibly due to some failure in the translation between underlying Foundation routines and AppleScript’s simpler proleptic Gregorian approach.
In Canada, I get January 1st of year 1 as well.
It looks odd and had me rubbing my eyes and wondering if there was some shorthand being used but nope, it refers to a day some 2022 years ago (depending upon how long a day is — I used 31556952 seconds). I have always assumed that there would be some era clock (e.g. unix/linux of 1970) or 1900/1904 (which I would always see in regard to the microsoft apps) but instead, that seems to be the beginning of applescript’s era.
Here’s an another odd one:
run script "date \"1/1/1\""
--> date "Monday, January 1, 1 at 00:00 "
run script "date \"1/1/0\""
--> date "Saturday, January 1, 1 at 00:00 "
I wonder how it comes up with the day of the week.
@Mockman, don’t bother yourself.
This is not the first time that string expressions of the form “A/B/C” have introduced errors into dates. It is better not to use them at all, or you need to be extremely careful when converting them to a local date. 
I’m not sure I made clear last night (I’d just got home after a long journey) that although the string compiled for the very early date “1/1/1” may match the input (except that the weekday’s wrong on my machine), the value of the date object produced doesn’t necessarily do so. On Ventura in the UK:
set date111 to (run script "date \"1/1/1\"")
--> date "Saturday, 1 January 1 at 00:00:00" -- (Should be Monday)
date111's {date string, time string}
--> {"Saturday, 1 January 1", "00:00:00"}
date111's {weekday, day, month, year, time, hours, minutes, seconds}
--> {Saturday, 30, December, 0, 75, 0, 1, 15}
date111 + 5 * (365 * 400 + 97) * days -- Five 400-year cycles later.
--> date "Saturday, 30 December 2000 at 00:01:15"
-- (ie. not date "Monday, 1 January 2001 at 00:00:00")
With regard to the result when specifying the year as 0, there’s no year 0 in the proleptic Gregorian calendar or its Julian predecessor, so the mathematical year 0 corresponds to the calendar year 1 BC. That’s what the “1” year number’s attempting to represent here:
set date110 to (run script "date \"1/1/0\"")
--> date "Thursday, 1 January 1 at 00:00:00" -- UK result, 1 BC.
date110 - 365 * days
--> date "Wednesday, 1 January 2 at 00:00:00"-- Ditto, 2 BC.
We were talking of date object generation without dependence of some language format.
We love internationalized version of date object generation routine.
use AppleScript
use scripting additions
use framework "Foundation"
set aDate to getDateInternational(2018, 12, 18, 9, 59, 35, "JST") --―year, month, date, hour, minute, second, time zone abbreviation.
--> date "2018年12月18日火曜日 9:59:35"
--Make a GMT Date Object with parameters from a given time zone.
on getDateInternational(aYear, aMonth, aDay, anHour, aMinute, aSecond, timeZoneAbbreviation)
set theNSCalendar to current application's NSCalendar's currentCalendar()
theNSCalendar's setTimeZone:(current application's NSTimeZone's timeZoneWithAbbreviation:(timeZoneAbbreviation))
set theDate to theNSCalendar's dateWithEra:1 |year|:aYear |month|:aMonth |day|:aDay hour:anHour minute:aMinute |second|:aSecond nanosecond:0
return theDate as date
end getDateInternational