Convert string to date

[DJ_Bazzie_Wazzie]

@Shane Stanley

You’re still missing MacUsrII point – if you pass a day of 31, and you do it when you system clock is showing a month with fewer than 31 days, you will get an error. You need to set the day to 1 (or less than 29, anyway) first, and then set the real day later.

But why should you support a wrong notated date in the first place? If someone types “31/2/99” shouldn’t he be given an error? Why should you try to fix that because he probably meant “31/1/99” or “31/3/99” and certainly didn’t meant “3/3/99”. Never trying to fix wrong inputted data into something unexpected, right?

@Shane Stanley

And you missed my point – if you don’t consult the system, you won’t realise that some of us use d/m/y order

Didn’t miss it, the given parameter was a static string

[McUsrII]

@Yvan Koenig

@ McUsr

It is not, even in AppleScript.

I guess that the engineers just knew that we will never have to write “it is” in an instruction so they decided to accept the wrongly spelled form.

set it is year to theYear means nothing.
According to the list of reserved words, the official syntax would be : set its year to theYear
and as accepting the wrong spelling set it’s year to theYear can’t hurt they didn’t reject it.

I was surprised because if I type:
if aa doesn’t equal 10 then set aa to 10
which is correctly spelled, the interpreter replace it by
if aa is not equal to 10 then set aa to 10

From my point of view it would have been logical to replace it’s by its automatically.

As I am curious, I saved the script :

set it's year to theYear

and the script :

set its year to theYear

Their datafork are identical.
The differences are only in their resource forks which as far as I know means that they are identical in terms of functionality but differ in aspect.

Yvan KOENIG (VALLAURIS, France) vendredi 12 juin 2015 16:07:20

Well, this particular work around a grammatical and syntactical ambiguity works for me. I must say that I’m forgiving, because after all, AppleScript is a damn cute language. I love the lists, and the fact that they are made just so, that you can easily translate code from other languages back and forth, which makes it very easy to learn things in. -Also to remove recursion. :lol:

Have a good evening everyone!

[Shane_Stanley]

@DJ Bazzie Wazzie

But why should you support a wrong notated date in the first place? If someone types “31/2/99” shouldn’t he be given an error?

That’s not MacUsrII’s issue, though. Sticking to m/d/y order, suppose the string is “31/1/2010”. That’s a valid date. But if you run your script today, current date will produce a date with a month containing only 30 days. So when you set its day to 31, it will roll over to 1. To be safe, you need to set the day to a value valid for every month before you change the month --then set the correct day.

[Shane_Stanley]

And one more suggestion for users of Mavericks and later:

use BridgePlus : script "BridgePlus"

set listOfDates to BridgePlus's datesFromStrings:{"02/20/99"} inFormat:"M/d/y"

It requires my BridgePlus script library. Overkill for one date, perhaps, but handy if you have a bunch of them.

[McUsrII]

@Shane Stanley

@DJ Bazzie Wazzie

But why should you support a wrong notated date in the first place? If someone types “31/2/99” shouldn’t he be given an error?

That’s not MacUsrII’s issue, though. Sticking to m/d/y order, suppose the string is “31/1/2010”. That’s a valid date. But if you run your script today, current date will produce a date with a month containing only 30 days. So when you set its day to 31, it will roll over to 1. To be safe, you need to set the day to a value valid for every month before you change the month --then set the correct day.

That is correct, and the month will be incremented as well, so it rolls over to the first of next month for instance. This is really Nigel Garveys world. It is a feature as much as a bug in other situation, where this is a great advantage during date calulations.

Setting the day to 1 covers 2 cases.

The first case is when todays daynumber of a month, is greater than the month you are wanting to end up with, and you start off by setting the month

The second case is when you set a day number first, and that daynumber is greater than the possible daynumber of the current month.

Either way, it is a risk of overflow of days into next month. And if you are to calculate the probability of this happening, then you must calculate with a probability of 50% since it either happens, or don’t, and then the likelihood will be far greater than you’d intuitively expect.

[Shane_Stanley]

@McUsrII

That is correct

And yet when I look at DJ’s code again, it’s not a problem. That’s because the maximum roll-over is three days, but he’s subtracting five days at the end – effectively making it a non-issue.

[McUsrII]

@Shane Stanley

@McUsrII

That is correct

And yet when I look at DJ’s code again, it’s not a problem. That’s because the maximum roll-over is three days, but he’s subtracting five days at the end – effectively making it a non-issue.

I wrote in general somewhere, higher above, on the previous page.

[Shane_Stanley]

@McUsrII

I wrote in general somewhere, higher above, on the previous page.

Sorry, I missed that. AppleScript dates really are lame. I look forward to being able to use:

set df to my NSDateFormatter's new()
df's setDateFormat:"M/d/y"
set theDate to (df's dateFromString:"2/20/99") as date

[McUsrII]

@Shane Stanley

@McUsrII

I wrote in general somewhere, higher above, on the previous page.

Sorry, I missed that. AppleScript dates really are lame. I look forward to being able to use:

set df to my NSDateFormatter's new()
df's setDateFormat:"M/d/y"
set theDate to (df's dateFromString:"2/20/99") as date

Or that we all used a convention of using the iso 8601 date format: yyy-mm-dd.

But then again, the 12 month calendar is totally lame in itself, we should really change to a 13 calendar month system. The Death and Life of the 13-Month Calendar - CityLab

[DJ_Bazzie_Wazzie]

@Shane Stanley

@DJ Bazzie Wazzie

But why should you support a wrong notated date in the first place? If someone types “31/2/99” shouldn’t he be given an error?

That’s not MacUsrII’s issue, though. Sticking to m/d/y order, suppose the string is “31/1/2010”. That’s a valid date. But if you run your script today, current date will produce a date with a month containing only 30 days. So when you set its day to 31, it will roll over to 1. To be safe, you need to set the day to a value valid for every month before you change the month --then set the correct day.

I see, I have updated the code to set the day first and then the month. Seems that non-English date notations (Dutch=dd/mm/yy) never have to worry about this and therefore I didn’t really saw the problem.

[Shane_Stanley]

@DJ Bazzie Wazzie

Seems that non-English date notations (Dutch=dd/mm/yy) never have to worry about this and therefore I didn’t really saw the problem.

We use dd/mm/yy down here too, and it has the same problem. Because it only happens when testing on particular days, it’s an insidious bug.