by David Empson
Updated: 2009-03-19
Introduction
New Zealand changed its daylight saving rules from September 2007. In order to handle times correctly, all computers need to be updated to know the new rules.
For Macintosh users in New Zealand, this was a problem in September 2007. Apple failed to release a system update prior to the new rule, which came into effect at 2 a.m. on Sunday September 30th, 2007 (NZ Standard Time). See my comments below on Apple's poor handling of this situation.
The subsequent release of Mac OS X 10.4.11 and Mac OS X 10.5 corrected the problem for those able to run the newer system versions, but anyone still running Mac OS X 10.4.10 or earlier (including any version prior to 10.4) will be affected by the problem.
It should be noted that this problem does not only affect the Macintosh: every computer in New Zealand must be patched, along with every computer in other countries which needs to know about the time in New Zealand. Microsoft released updates or instructions for several versions of Windows, but some people might not have installed them, and those with older operating systems may not have any options.
Under the old rules, daylight saving started on the first Sunday in October, and if nothing is done about it, the Mac will continue to use that rule, resulting in the time being one hour slow for the week from September 30th to October 6th. The same problem will occur in late March, as the end of daylight saving has changed from the third Sunday in March to the first Sunday in April.
For some Mac users, this will only be a cosmetic problem, resulting in the computer showing the wrong time for a week.
Most Mac users now rely on applications which depend on correct knowledge of how the local time relates to the time in the rest of the world, and for any such application, having the wrong local time will result in problems. iCal is the main example of a commonly used application which will be affected.
This article summarises the anticipated problems Mac users might face and discusses various ways of dealing with the rule change.
Please note that I am updating this article as more information comes to light. In particular, see the observed problems section.
Options
The following major options are available for dealing with the problem.
- Install a third party patch to update the New Zealand rules on your system. Two patches are available for Mac OS X 10.4.10, one for 10.3.9.
- Temporarily change your time zone. This has some potential problems.
- Set your clock ahead an hour manually. This has potentially major problems for some people.
- Do nothing, so your clock will be an hour slow for the week in early October, and for two or three weeks in late March. See anticipated problems.
See my recommendations at the end of the article.
Anyone running a server of some kind will almost certainly need to patch their system, especially if storing or displaying accurate times is an essential function of the server.
A Locally Produced Patch
Wellington-based developer Glenn Anderson has written patches for Mac OS X 10.3.9 and 10.4.9/10.4.10 which set up the new rules for New Zealand. They are available for download from his web site: http://www.mactcp.org.nz/nzdt.html.
Warning: it was subsequently discovered that there is a problem with the 10.3.9 version of Glenn's patch. It turns out that 10.3.9 cannot cope with different years having different daylight saving transition rules, and the patch only fixed the daylight saving transition rule for September/October. This means that even with this patch applied, the computer thinks daylight saving will end in mid March instead of early April, resulting in the wrong time being displayed for two or three weeks in late March every year.
Glenn is best known in the Mac world as the author of Eudora Internet Mail Server (EIMS).
The 10.4 version of the patch has been tested by several other members of the Wellington Mac developer community (including myself) and works well enough to avoid most of the potential problems with running an unpatched system.
Richard Smith from Waikato University has converted Glenn's patch into a standard package installer (for 10.4 only). This can be used with Apple Remote Desktop to do mass installation for large institutions. It is available here.
You will need to restart the computer after applying any version of the patch, to ensure everything is using the new rules.
As with any third party patch, you need to decide for yourself whether to risk possible side effects of running a modified system. In particular, note that this patch doesn't cover everything: there are some parts of Mac OS X and applications which have their own copy of the time zone rules, and this patch doesn't update them. It will support any application which uses the standard system mechanisms for converting between local and universal time (including POSIX/UNIX applications and most Mac graphical user interface applications).
Java and WebObjects are known to have their own rules, which are not updated by this patch.
Installing 10.4.11 or 10.5 will completely replace the files which are modified by Glenn's patch (or Richard's version).
System Requirements
The following table summarises the requirements for installing either version of Glenn's patch. To find out what system version you are running at the moment, use the "About This Mac" command under the Apple menu (top left corner of the screen).
In most cases, you will need to bring your system up to the latest available version prior to installing the patch. To get your system updated to the current version, you can use "Software Update" under the Apple menu. Note that some of the required system updates are very large, and if you have a dial-up connection this may be impractical as the largest updates may take most of a day to download. As a rule of thumb, you should be able to download about 20 MB per hour with most dial-up modems.
| Current System Version | Requirements |
| 10.4.11 or later | No patch required. System has the correct rules for New Zealand. |
| 10.4.9 or 10.4.10 (Tiger) | No special requirements. Just download and install this patch, or update to 10.4.11. |
| 10.4.8 | The patch may work if you first install Apple's Daylight Saving Update 2007-1001 (Tiger) but we haven't tested this. We recommend updating to 10.4.11. You can apply this patch if you update to 10.4.9 or 10.4.10 but can't update to 10.4.11 for some reason. |
| 10.4.0 through 10.4.7 | We recommend updating to 10.4.11. You can apply this patch if you update to 10.4.9 or 10.4.10 but can't update to 10.4.11 for some reason. |
| 10.3.9 (Panther) | You must install Apple's Daylight Saving Update 2007-001 (Panther) before applying this patch. Note that Glenn's 10.3.9 patch only corrects the rule for the September/October transition, not the March/April transition. |
| 10.3.0 through 10.3.8 | You must download and install the 10.3.9 update and the daylight saving update before applying this patch. Note that Glenn's 10.3.9 patch only corrects the rule for the September/October transition, not the March/April transition. |
| 10.0 through 10.2.8 | No solution is available, short of upgrading to a newer version of Mac OS X. |
| Mac OS 8.5 through 9.2.2 | The daylight saving rules for Mac OS 8 and 9 can be patched manually. Glenn has an application to do this. |
| Mac OS 8.1 or earlier, Apple II | Automatic daylight saving changes are not supported, so no patch is necessary. You will have to turn daylight saving on or off manually, as always. |
Technical Details
Glenn's patch operates by modifying the following files:
- /usr/share/icu/icudt32b.dat
- /usr/share/icu/icudt32l.dat (Mac OS X 10.4 only)
- /usr/share/zoneinfo/Pacific/Auckland
- /usr/share/zoneinfo/NZ
The first two files contain a collection of country-specific information used by a large number of applications on Mac OS X, including all those based on the Core Foundation, Carbon and Cocoa frameworks (all Mac OS X graphical user interface applications.) Glenn's patch operates by replacing the time zone rules within these files. The "b" file is used on PowerPC Macs, the "l" file on Intel Macs (hence it doesn't exist on Mac OS X 10.3.9).
The last two files contain time zone conversion rules for mainland New Zealand which are used by many applications written based on the POSIX standards or those using standard C library calls to find out the local time. This includes nearly all open source applications ported from other Unix/Linux systems.
Apple's Inaction and Response
The new rules were introduced by the New Zealand Government in April 2007. Between April and September, Apple released two minor system updates (10.4.9 and 10.4.10) which did not incorporate the new rules. Nor did they release a separate patch. There was a special daylight saving update prior to the US rule change earlier this year, which was released for both 10.3.9 and 10.4.8.
A similar problem affected Western Australia in 2006. According to an Apple representative for Australia and New Zealand, Apple released a patch specifically for Western Australia about three weeks before their rule changed. It was made available via Apple's web site and the Western Australian government site, and e-mail notification was sent to registered Mac users in Western Australia. It wasn't distributed via the normal Software Update mechanism, so some Mac users in Western Australia may have been unaware of it, and most people elsewhere in the world would have no idea it existed unless they happened to stumble upon it on Apple's web site. Any Mac user in the world who needed to know the time in Western Australia would have had problems.
It seems that Apple doesn't think New Zealand is important enough to warrant an update in any form, even though we have a higher population than Western Australia.
At the time, Apple's only relevant response was to post an article suggesting that New Zealand users deal with the problem by setting their clock ahead an hour for a week. It did not mention any of the possible side effects of doing this, some which I've summarised below. (The article was subsequently updated to say that the correct rules are applied in 10.4.11 and 10.5.)
Other operating system vendors such as Microsoft seemed to have no problem updating their systems in time, and notifying their customers about the problem. Apple were dragging the chain, and it was very disappointing.
It is likely that there will be an increasing frequency of daylight saving rule changes around the world, e.g. for special events like the Olympic Games, or to reduce energy consumption by aligning waking and business hours with daylight hours. Apple should have a standard policy of doing worldwide distribution of daylight saving updates in a prompt fashion. At the very least, they should update to the latest available daylight saving rules whenever they do a general system update.
Apple did fix the NZ rules in 10.4.11 and 10.5, but they weren't released in time, and the rules were not fixed for any earlier system versions.
This means that anyone still running 10.4.10 or earlier should consider updating or upgrading to a later version, or installing a third-party patch to fix the daylight saving rules.
Anticipated Problems
Problems should be expected in the week between September 30th and October 6th 2007, or March 16th and April 5th 2008. These problem will recur in subsequent years on an unpatched system.
If you do nothing, then during those weeks, your computer will be showing the wrong time (it will be an hour slow), and you will need to schedule events (e.g. in iCal) an hour earlier than they really occur.
If you install a patch or system update which fixes the daylight saving rules, any previously entered iCal events scheduled during those weeks will be adjusted ahead by an hour, along with your current time.
This is because iCal along with most of Mac OS X operates on the basis of universal time (UTC or GMT), not local time. It shows the wrong local time, because it is using the old rule, but when the rules are corrected, the scheduled events are corrected along with the system time.
Some applications may be operating based on local time. If so, they will continue to show the wrong time for scheduled or recorded events after you apply a patch or system update.
Problems for Mac users outside New Zealand
For any Mac user outside New Zealand, the main problem you are likely to face is that your computer will be misreporting the time in New Zealand. For example, if you have a World Clock showing New Zealand time, it will be an hour slow during the week of September 30th to October 6th (and again in late March).
If you use iCal with time zone support enabled, events entered in New Zealand time during those weeks will shift by an hour once your system is updated to use the correct rules.
For Mac users in other countries, the only way to avoid these problems is to patch your system.
Potential Workarounds
For Mac users in New Zealand, there are at least two ways to fix the local time on your computer without having to patch your system.
Setting the clock ahead an hour
A temporary option (and Apple's recommendation) is to manually set your clock ahead by an hour. To do this, you must first turn off automatic time updates, and set your clock back to the correct time when the old daylight saving rule starts (October 7th).
Setting the clock ahead an hour has some potential problems. Here are a few I've thought of, but there are probably more:
- Your computer will have the wrong idea of what time it is in the rest of the world. If you do anything involving international time zones, such as talking to people overseas or bidding on eBay auctions, you will need to rely on an independent world clock instead of the computer, or remember that your computer is an hour fast for everywhere else in the world.
- Anyone running a web server or similar application with a database behind it that needs to know time everywhere in the world will have problems due to incorrect time information being recorded in the database.
- Anything involving astronomy or the sun (such as sunrise/sunset times in applications like Google Earth) will be out by an hour. Astronomy applications will be rendered useless because they depend on accurate time information.
- All sent and received e-mail will appear to be at the wrong time and may be sorted in the wrong order, for both you and people to whom you send e-mail.
- Documents which are exchanged with other computers and which contain times may have those times change when displayed on another computer system.
- Files transferred to or from other devices you own (e.g. digital cameras) may have incorrect time information and incorrect creation or modification times.
- Networked computers which use the Kerberos system for centralised password management will not be able to connect to the Kerberos server if their clock is set an hour ahead.
If a daylight saving patch/update is installed after you had manually adjusted the clock, you may notice problems such as:
- Events already entered in iCal may shift by an hour.
- Files modified while the clock was set wrong will appear to have been modified an hour later. This might interfere with tasks like file backups, and may cause loss of data due to a file copy going the wrong way, or an unnecessary repeat backup of files.
Changing time zone temporarily
It has been observed that there is another time zone available in System Preferences which is at the same UTC offset as New Zealand but which is in daylight saving for the week starting September 30th 2007. Switching to this time zone may be a reasonable temporary solution for some people, avoiding the need to patch your system.
The time zone in question is Anadyr, in Russia. Daylight time in Anadyr lasted until October 28th 2007.
I haven't checked whether Anadyr is a suitable option for dealing with an incorrect time zone rule in late March, or whether it will work in late September for 2008 and later years.
If you change your time zone to Anadyr on or after September 30th 2007, your Mac will display the correct local time (in most places), and the correct time for other countries. You will need to switch back to the New Zealand time zone on or after October 7th 2007 (and no later than October 27th 2007).
This is also not a perfect solution, and these are some of the side effects you should expect:
- File creation and modification times will shift by an hour for most files on your system.
- If you do any kind of search for files modified on a certain date, some files modified close to midnight on September 30th 2007 or earlier will appear on the wrong day.
- iCal with time zone support enabled needs to be handled carefully.
- A World Clock showing the time in New Zealand will be an hour slow, as will anything else which specifically displays New Zealand time rather than the local time.
- Anything which displays the time zone name will show ANAST instead of NZDT.
When you switch to the Anadyr time zone, most files on your system which were created or modified before September 30th 2007 will appear to have been created or modified either an hour earlier or later. This is because the file times are stored in UTC (universal time), and are displayed in your current local time.
Anadyr and New Zealand have daylight saving in opposite halves of the year, so files modified during NZ daylight saving time will appear an hour older in Anadyr standard time, and files modified during NZ standard time will appear an hour newer in Anadyr daylight saving time.
If you use any backup system which checks for modified files based on their time, it might misbehave because most of your files appear to have been modified at a different time from when they were last backed up. This could result in extra backups or loss of data due to a file copy going the wrong way. It depends on whether the backup system operates using local time or universal time, which might be affected by the file system used on your backup device. In particular, restoring files from backup might result in a permanent change to the creation and modification times.
If you have enabled time zone support in iCal's preferences, and you set iCal to display events in the Anadyr time zone, most events prior to September 30th 2007 and after October 28th 2007 will appear to shift by an hour (for the same reason as the file times changing), so you should leave it displaying New Zealand time.
Events entered in the week starting September 30th will be shifted by an hour when your system is subsequently updated to correct the New Zealand time rules. You might be able to avoid this by manually setting those events to be in the Anadyr time zone instead, or by setting iCal to the Anadyr time zone before entering events for that week.
Note that iCal is normally set to operate with time zone support disabled. In this case, there will be minimal side effects in iCal if you switch to the Anadyr time zone, unless you subsequently enable time zone support in iCal.
Observed Problems
I will update this section as more information comes to light with problems people are actually experiencing around the daylight saving transition. Please contact me if you have anything to report.
System Bug affecting old applications
Leading up to the daylight saving transition, WelMac member David Jackett observed that some applications were saving files with incorrect creation and modification times. Further testing by myself and friends has revealed the following behaviour. It should be noted that this is not due to patching the system. The same problem occurs (a week later) on an unpatched system.
Starting at 2 pm the day before the beginning of daylight saving (Saturday 29th September for a patched system, Saturday 6th October for an unpatched system), certain applications are saving files with creation or modification times which are one, two or three hours too early.
The problem stops as soon as the daylight saving transition is crossed, so only files saved within that twelve hour period are affected.
The affected applications include AppleWorks, Eudora, MacSoup, FileMaker Pro 6 and GraphicConverter.
These are all applications which were originally written for Mac OS 9 or earlier and which have been ported to Mac OS X. They are using the "Carbon" framework, and probably using old File Manager application programming interface which uses local times for files rather than universal times. Some of these applications are current versions and really should be updated by the authors to use more modern file system APIs.
Glenn has investigated this and tracked it down to a bug in a specific function in Mac OS X. It affects all time zones, but the "margin of error" varies depending on the country's offset from UTC. It is most noticeable in New Zealand because we are 12 hours away from UTC.
This bug has probably been in Mac OS X since the very first version. It just hasn't been noticed before.
System Bug affecting World Clock in Dashboard
Shortly after the daylight saving transition, I noticed that all my Dashboard World Clocks were showing times which were an hour slow, for all time zones except my local one. Some testing revealed that this was a short term problem: it only lasts for twelve hours after the daylight saving transition. From 3 pm (local time), all clocks were correct again.
This problem is not due to patching the system. The same problem occurs (a week later) on an unpatched system. This is a bug in Mac OS X (possibly in WebKit or its Javascript implementation), very similar to the previous one. We haven't investigated further.
Microsoft Office
The 2001 edition of Microsoft Office for Mac OS X ("Office v.X") contains its own set of time zone rules, rather than using the Mac OS X standard rules. The same applies to Office 2004 prior to version 11.3.3. For these versions of Office, events in Entourage during the week after September 30th 2007 will jump by an hour when the system is patched to correct the NZ daylight saving rules.
Updated copies of Entourage from Office 2004 uses the standard system daylight saving rules, but might still exhibit time shifts for previously entered events if you patched the system after creating events in the week of September 30th.
Further information on the time zone handling in the 11.3.3 update is available here. There is also an unofficial fix for Office v.X which is based on the US rule change earlier in 2007. It can be adapted to the NZ rule change.
Kerberos
Kerberos is a centralised password management and authentication system used on larger computer networks. It has a requirement that the client and server clocks are in sync to within a few minutes, which means that client and server computers must have automatic clock synchronization enabled to avoid random problems if their clocks drift out of sync.
If the server computer has been updated to the new daylight saving rules and the client computer has not, then the client is at risk of being unable to connect to the Kerberos server, which means it can't connect to any other servers which depend on the Kerberos authentication.
Setting the client's clock ahead an hour will cause the Kerberos authentication to fail. Leaving the client clock an hour slow or changing time zone might work, but the best solution is to patch all client computers to update their daylight saving rules.
Recommendations and Conclusion
The best solution would be if Apple had released a patch or system update prior to September 30th 2007, and everyone had time to install it. You can avoid most problems by installing a third-party patch (such as Glenn's) prior to September 30th, or minimise problems by doing it as soon as possible afterwards.
If a patch or system update is installed, please re-check all the times for events in iCal and other calendar systems for the week of September 30th to October 6th, as you may find events you already entered have shifted ahead by an hour. You should also expect files saved within that time period (prior to the patch being applied) to move ahead by an hour.
If you are willing to risk the possible side effects, setting your time zone to Anadyr for a week is a reasonable solution for most Mac users.
If you don't want to patch your system (or are unable to do so) and don't want all your file times to change (by switching to Anadyr), I recommend leaving your clock set an hour slow for that week, and deal with issues like iCal event scheduling by entering them an hour early. This is better than setting your clock ahead an hour.
In summary, no matter what solution you use, expect scheduling problems for a week!
Other References
About the Author
David Empson is the President of the Wellington Macintosh Society, and has been involved with the society since its foundation (as "Wellington Apple Users Group") in 1984. He has been involved with technical support and programming Macintosh computers since 1996, and Apple II computers prior to that, and does embedded systems programming in his day job. He now knows more about daylight saving problems than he ever wanted to.
Contact: president@welmac.org.nz
Permission is hereby granted for other Apple user groups and publications to reprint this article in its entirety. Please contact me if you wish to publish an abridged version, and links to this article are welcomed.
Thanks to members of the wellDeveloped group for their assistance with this problem, and especially to Glenn for writing the patch and to Allan Honey for testing and debugging.
Revision history
| 2007-09-23 | Originally published |
| 2007-09-26 | Corrected details about Western Australia patch (twice) |
| 2007-09-28 | Link to Richard Smith's installer package version of the patch Further commentary on Western Australia patch and Apple's general handling of daylight saving |
| 2007-09-30 | Observed bug with file timestamps with old applications Observed bug with World Clock |
| 2007-10-02 | Suggestion of using Anadyr time zone Options summarised Updated wording and rearranged some sections Observed time shift in Entourage v.X |
| 2007-10-03 | Updated notes on Microsoft Office Observed problem with Kerberos |
| 2009-03-18 | Problem discovered in Glenn's patch for 10.3.9 Revised wording for historic perspective Noted correct rules are in 10.4.11 and 10.5 |