At 08:21 05/01/2004 -0600, you wrote:
There have been issues in the past with the slow behavior of the calendar..
Its a lot of JS to load.. There was even talk of splitting the calendar out
into its own add-in to not force the extra startup delay on people who are
not interested in running it...
, and then include them in the installation executable.
MLL
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Will Dean
Sent: Monday, January 05, 2004 3:43 PM
To: [EMAIL PROTECTED]
Subject: Re: [DQSD-Users] Revised 2004 - holidays.sg.xml
At 08:21 05/01/2004 -0600
I agree. To me, this seems like the best of most worlds.
Kim
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of MLL
Sent: den 5 januari 2004 20:13
To: [EMAIL PROTECTED]
Subject: RE: [DQSD-Users] Revised 2004 - holidays.sg.xml
IMHO, the best
And just a thought for everybody. Aren't singaporian, canadian, us
holidays predictable several years in advance ? That would make things
leaner. Example : after some research, I could build a holidays.fr.xml with
virtually no limit of year (though I stopped at 2020). Easier.
At least for the
Hi Kim,
Anyway, there seem to be a couple of rules sufficient to
express an entire holiday season:
- Fixed dates
- Dates relative to Easter (Easter sunday is
algorithmically available for any year)
- Nth weekday in month
- Weekday in between two dates (i.e. Saturday in between
31/10 and
