Re: date/Snow Leopard changed
Re: date/Snow Leopard changed
This is a bit of a rant, but here is the bottom line:
I seriously cannot fathom how I would write a handler that could read
all the possible dates that applescript currently interprates as valid
dates which is what I would need to do if I want certain scripts to
work outside the US.
If you're receiving a block of text which is actually a date, say
from an external file, you should know the format so be able to
parse it appropriately.
The issue is that we often get files or other text input where we
don't know precisely what the format is, or sometimes the dates are
not exactly formatted correctly or consistently, but appleScript would
correctly and consistently derive the date no matter where the script
was run or what the local settings were. It's an incredibly powerful
feature that correctly divines valid dates from all sorts of textual
inputs.
We've lost part of that and our scripts that have been installed and
in use for years will start breaking as our international users
upgrade to SN.
That is not good.
Moving forward AppleScripters will have to develop their own methods
for manipulating dates, which will certainly be slower, less reliable
and more cumbersome than the what we got for free.
I'd venture to say a lot of scripters will not want their scripts run
on "foreign" computers because of the headaches this will cause.
Would it be possible for apple to fix things this way:
date someStringwithAdate using {region: "United States", calendar:
"Gregorian")
it would default to the localized settings if nothing is specified.
>shane>If the "using" parameter was compulsory, probably....
I would say the using parameter would be optional, defaulting to the
localized settings as the current release does now, but needed only if
the script writer was expecting the data to have a different date
format than the runtime user.
>Shane>But what you're really asking is for them to keep the existing
method, one way or the other ...
Yes....
>>> ....because although it's broken for some other people, it works
for you.
No, what you (or Apple) are saying is since it didn't work for
everyone this feature should work for no one, rather than adding
flexibility that would work for everyone.
>>>It's the same argument that was used in the transition to Unicode,
in a sense.
I didn't make that argument, because long before AppleScript made the
jump to unicode we could see it coming. We knew it would be there,
and, we still had the ASCII alternative that's still working.
The jump to unicode didn't break my scripts.
>>>But the reality is that proper international support is an
incredibly complex business, and the best (probably *only* in
practical terms) way to support it to use collaboratively developed
open source software, such as the ICU code Chris referred to. That's
what Mac OS is using -- it's no longer an issue of some code that the
AS team, or some other Apple team, wrote.
Yes the fact that it is complex is why it is better handled at the
system level as opposed forcing AppleScripters to try and write
scripts that will handle the wide variety of localizations.
>>>Apple can't afford to have dates screw up on those millions of
iPhones it hopes to sell in China, and it doesn't make sense to use
one set of code for them and another for a relative handful of
AppleScript users.
>>>I know I can think of a lot of other things I'd rather see the AS
team spend precious engineering resources on.
I can't. I see this as broken, in a fairly brutal way. With no
warning, with no "deprecated" appearing in the dictionary with no
effort at backward compatibility --overnight scripts break when used
in a different location.
Does that seem right? Suddenly all the scripts that read dates
correctly for years suddenly don't work in other countries because
Apple is improving localization?
>>>The good news is this means the underlying code should be solid,
safe, consistent, maintained, and support all languages.
Our scripts won't work, but at least the underlying code is good?
>>>>It also means its features aren't set by Apple, or a small subset
of Apple clients who happen to use AppleScript.
Actually I'm all in favor of the improvements in the underlying code,
I just want more flexibility from AppleScript in accessing the
information
>>>>Feel free to lament the passing of something that was once free
and easy, but understand that (a) it wasn't done on a whim, and (b)
there's no turning back.
I don't want to turn back, I just hate to see AppleScript further
marginalized. And I especially hate to see my scripts break.
Something like this:
date someStringwithAdate using {region: "Australia", calendar:
"Gregorian")
wouldn't be turning back, wouldn't change the underlying code, but
would simply add more flexibility to applescript.
ES
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden