Posts Tagged OS X
OS X: Fix Argentina DST October 2009
Well, at almost the last minute, DST was cancelled in Argentina this year. And this broke things, mostly computers. (Not for the first time either, the same thing happened two years ago here).
The debian folk came out with a fix at the last minute: so that fixed the linux machines, but OS X is a slower beast to move, so it’ll be a while before any change works its way through. In the meantime, Mac users in Argentina are left with broken clocks.
Argentina_DST_Update.pkg – for 10.6.x only!
I am no Mac expert, and this isn’t entirely tested, so be warned.
Anywho, this is how to update the tz data (aka zoneinfo), which should, in theory, fix the problem:
mkdir tzfix
cd tzfix/
curl ftp://elsie.nci.nih.gov/pub/tzdata2009n.tar.gz | tar -zxvf -
vi +219 southamerica
Change the two lines:
Rule Arg 2008 max - Mar Sun>=15 0:00 0 -
Rule Arg 2008 max - Oct Sun>=15 0:00 1:00 S
to the following
Rule Arg 2008 2009 - Mar Sun>=15 0:00 0 -
Rule Arg 2008 only - Oct Sun>=15 0:00 1:00 S
(i.e. just two words to change). If it makes you feel better, here’s a diff.
Ok, save & close, and then compile it as follows:
sudo zic southamerica
sudo cp /usr/share/zoneinfo/America/Argentina/Buenos_Aires /usr/share/zoneinfo/America/Buenos_Aires
The sudo is necessary because you’re changing /usr/share/zoneinfo.
And that’s mostly it. Verify that it worked as follows:
zdump America/Argentina/Buenos_Aires
America/Argentina/Buenos_Aires Sun Oct 18 20:43:42 2009 ART
(note that the timezone is now ART, not ARST as previously).
So that fixes things for most of the command-line stuff. But you’ll notice that the clock on your desktop, iCal, and others, are still incorrect. We need to fix the ICU database also. Thankfully the latest sources are available for this from apple itself:
curl -O http://www.opensource.apple.com/tarballs/ICU/ICU-400.37.tar.gz
tar -zxf ICU-400.37.tar.gz
cd ICU-400.37/icuSources
ICU doesn’t come with the tzdata, but the readme in tzcode helpfully notes that if we place the tzdata*.tar.gz file in tools/tzcode/ it will be compiled automatically. You can pack up your own tzdata2009n.tar.gz that we used earlier if you wish, or use the one I prepared here:
cd tools/tzcode/
curl -o tzdata2009o.tar.gz http://brickybox.com/wp-content/uploads/2009/10/tzdata2009otar.gz
cd ../../
./runConfigureICU MacOSX --with-data-packaging=archive
gnumake
sudo install -o root -g wheel -m 0644 -Sp data/out/icudt40l.dat /usr/share/icu/icudt40l.dat
And that’s it. We have a new ICU database. Reboot to see the changes.
Update (21st October):
This technique works on the iPhone too. The iPhone already has zic (well, at least my one has), so you can simply copy your modified southamerica file onto the phone somewhere, and run (as root):
zic southamerica
cp /usr/share/zoneinfo/America/Argentina/Buenos_Aires /usr/share/zoneinfo/America/Buenos_Aires
And you can simply copy the data/out/icudt40l.dat you created for OS X into /usr/share/icu/icudt40l.dat on the iPhone. It causes Springboard to crash, but after a reboot everything works perfectly.
Update (10th November): I can’t believe it, today 10.6.2 update broke the damn icu stuff again.
mkdir 10_6_2_fix
cd 10_6_2_fix/
curl -O http://www.opensource.apple.com/tarballs/ICU/ICU-400.37.tar.gz
tar -zxf ICU-400.37.tar.gz
cd ICU-400.37/icuSources/tools/tzcode/
curl -O ftp://elsie.nci.nih.gov/pub/tzdata2009r.tar.gz
cd ../../
gnumake
sudo install -o root -g wheel -m 0644 -Sp data/out/icudt40l.dat /usr/share/icu/icudt40l.dat
Thanks to Jonathan Tapicer for pointing out that the tzdata file name has been updated (now at version R).
Update (5th February): I’ve had several requests to package this up in an installer, so here goes:
Argentina_DST_Update.pkg – for 10.6.x only!
(I don’t have a 10.5.8 any longer, so I can’t compile for it, sorry)
Popularity: 16% [?]
Java 1.6 on OS X
Today I was presented with the following error
java.lang.UnsupportedClassVersionError: Bad version number in .class file
My first instinct was of course that I must be using an older vm on the machine in question (an OS X 10.5.6 server), but no, java 1.6 was installed on this machine:
~$ ls -alF /System/Library/Frameworks/JavaVM.framework/Versions/ total 56 drwxr-xr-x 14 root wheel 476 25 Sep 10:43 ./ drwxr-xr-x 12 root wheel 408 1 Nov 18:28 ../ lrwxr-xr-x 1 root wheel 5 25 Sep 10:43 1.3@ -> 1.3.1 drwxr-xr-x 3 root wheel 102 2 Nov 2007 1.3.1/ lrwxr-xr-x 1 root wheel 5 25 Sep 10:43 1.4@ -> 1.4.2 lrwxr-xr-x 1 root wheel 3 16 Jun 2008 1.4.1@ -> 1.4 drwxr-xr-x 8 root wheel 272 25 May 2007 1.4.2/ lrwxr-xr-x 1 root wheel 5 25 Sep 10:43 1.5@ -> 1.5.0 drwxr-xr-x 8 root wheel 272 25 May 2007 1.5.0/ lrwxr-xr-x 1 root wheel 5 25 Sep 10:43 1.6@ -> 1.6.0 drwxr-xr-x 8 root wheel 272 16 Jun 2008 1.6.0/ drwxr-xr-x 8 root wheel 272 25 Sep 10:43 A/ lrwxr-xr-x 1 root wheel 1 25 Sep 10:43 Current@ -> A lrwxr-xr-x 1 root wheel 3 25 Sep 10:43 CurrentJDK@ -> 1.5
A little further investigation revealed that, even though 1.6 is installed, 1.5 is still firmly the default:
~$ java -version java version "1.5.0_16" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-284) Java HotSpot(TM) Server VM (build 1.5.0_16-133, mixed mode)
Thankfully, this can be changed by aliasing java to the 1.6 version:
~$ alias java=/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Commands/java ~$ java -version java version "1.6.0_07" Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode)
Do this in your .profile to make it stick.
In fact the solution was simpler than the above for me, I just had to put
export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home
in my tomcat startup script (since I only needed the 1.6 jvm in tomcat).
Popularity: 7% [?]
Calling SAP from PHP (on OS X)
You’d think it’d be easy eh?
- My first google turned up SAPRFC, an extension module for php which allows direct ABAP calls from php. ‘Perfect’, I thought, until I discovered that it is now essentially unmaintained, and it seems that no one ever tried it on OS X in the first place.
- Very very happy was I then when I discovered its (very new) successor: sapnwrfc. But no one has bothered to compile this yet on OS X either (and, like its predecessor, it requires the SAP RFC SDK, which I don’t have). And besides, it really is very new, just a month or so old – not suitable for production then.
- So I resigned myself to using another language to bridge the gap. My first thought (my first hope really), was perl. This turned up SAP::Rfc, written by the same guy who’s creating sapnwrfc. But this also requires the SAP RFC SDK, and I couldn’t find anyone who’d ever compiled this on OS X.
- So why not Java? The SAP client my employer would have me use is pure Java, so surely I could use the same technologies?
And this is where I stand at the moment: Use PHP/Java Bridge to call from php to Java, and SAP JCo to call from Java direct to SAP.
Yes, it’s cludgy, horrible, and sounds stupid. And it probably is stupid. But it’s how I plan to proceed for the present. Tomcat will host the Java VM, and – if all the PHP/Java Bridge documentation is to be believed – there will be no need for Java ‘glue’ code, I should be able to use the JCo code directly in php.
If I live through the experience I’ll post more info about this soon.
Some pre-emptive defence: I know there are other technologies which would be preferable to my current solution – but I can make no changes whatsoever to SAP, this severely restricts my options.
Popularity: 8% [?]