I'm working on my Universal Scheduling Language (USL) specification, and in the process I am learning some little intricacies about world calendars and scheduling.
Calendar
For instance, it seems that most of the world has adopted the Gregorian calendar, as far as business is concerned. However some Arab countries use both the Gregorian and the Islamic calendars including Saudi Arabia which requires that dual calendars be maintained for international business.
Weekends
In the U.S. there are lots of cultural sayings related to Fridays and Mondays in the work week in relation to Saturday and Sunday being the weekend. However, the "weekend" is still a relatively new concept in parts of the world, and has been adopted in different ways. Some observe the weekend on Thursday and Friday, other start on Friday at noon, and others still on Saturday at noon. Originally I had defined weekend rules as IfSaturday and IfSunday. Given the differences around the world, it may be more accurate to describe weekend rules as IfFirstWeekendDay, IfSecondWeekendDay, and possibly IfThirdWeekendDay. I may need to further describe the weekend days with a start time and/or end time.
New Years
Times Square and *** Clark are two of the most notable icons of New Year's Eve. However, not all parts of the world share our enthusiasm for the 1st of January. Historically, the Romans and Babylonians celebrated New Years at the beginning of the Vernal Equinox; the first day of spring. Iran still follows this observance today. Among others, Thailand, Nepal, Cambodia and India celebrate New Years in April. In China New Years occurs based on the Chinese lunar calendar and usually occurs in late January or February.
Daylight Saving Time
Spring forward, fall back. Originally proposed in a 1784 satire, it wasn't until the early 1900's that daylight saving time was observed. However, like weekends and New Years, the whole world does not uniformly recognize DST. In fact, only a small portion of the world's population observes DST. Most of Africa and Asia do not. There are differences even within the political borders of the United States. Arizona and Hawai'i do not observe DST, but the Navajo Nation in Arizona does. Until recently, Indiana was split between Eastern Time and Central time, and many counties did not observe DST at all. Internationally, China spans five time zones, but does not observe DST, and some Australian provinces observe DST, but others do not. There are too many others to mention.
From a financial business perspective, this can be very confusing when trying to determine a business day and when automated jobs should be run. For example, a Canadian entity wanting to purchase securities on the New York Stock Exchange (NYSE) needs to know whether the New York Stock Exchange (NYSE), the US Federal Reserve and the Bank of Canada are all open for business. Anyone with a browser could certainly figure this out in less than a minute, but what about automated systems?
These are some of the issues and complexities I am encountering while writing my Universal Scheduling Language specification. For now, I think version 1.0.1 (I wrote version 1.0 awhile ago but never released it) will only include support for the Gregorian calendar, as most of the world's businesses recognize it. It will be interesting to integrate scheduling based on multiple calendars in future versions. Weekend rules will take some re-tooling to support the difference days of the week that are observed as the "week end".
Originally, USL was part of a larger specification I was writing called Data Flow Execution Language (DFEL). I decided that it would be more concise to release and push adoption of USL first, and then make it a component in DFEL.
Keep an eye on www.DFEL.net, as I plan on releasing USL 1.0.1 shortly. Following the USL 1.0.1 specification, I will be putting together the Globalization Metadata Server (GMS) specification. The constant fluctuations in DST observance, holiday scheduling and other variables make it imperative to have a common and public metadata repository for such information, hence GMS.
The goal of all this: to create common, public and open standards for business use worldwide which provide a unified system of automation scheduling.
Also, I'm looking for persons interested in getting involved. Specifically, technical folks to proofread my drafts and anyone with experience in standards work. Anyone else who is interested in these topics is certainly encouraged to get involved. Check out the website, as I'll have contact information up shortly.
Any thoughts?