JP2008537189A5 - - Google Patents

Description

Calculator and method for converting Julian day and Chinese date Detailed description

The present invention relates to a computer for performing the method and such a transformation for converting between Julian dates day numbers and Chinese calendar (Julian Calendar) (Chinese Calendar) .

  The term computer as used herein is interpreted to extend to encompass any form of electronic computing device and includes portable personal computers such as data recording devices, personal digital assistants (PDAs), etc. Communication with any form factor, including any type or form of computer, mobile phone, smart phone, communicators that combine communication, image storage and / or playback, and computing capabilities within a single device Devices and other types of wireless and wired information devices including digital cameras, MP3s, other music players and digital radios.

The Chinese calendar is very complex. The Chinese calendar is not a pure solar calendar, such as the standard secular Gregorian calendar. The solar calendar is based on the solar cycle of the year and ensures that the seasons appear on approximately the same date every year. The disadvantage of a pure solar calendar is that the phase of the moon changes throughout the month and is not associated with a specific date in the month.

It is neither a Chinese calendar nor a pure lunar calendar such as the Muslim calendar. The lunar calendar ensures that the phases coincide on the same day of each month, based on the period of one month of the month. The disadvantage of a pure lunar calendar is that the season changes throughout the year and is not related to any month.

The Chinese calendar is the lunisolar calendar. These are similar to the lunar calendar in that the month is based on the lunar cycle, so the phases coincide with the same day of each month. However, they are also associated with the sun in that they require that every season of the year occur in the year in approximately the same month of each year. This condition is satisfied by inserting a leap moon every two or three years, ensuring that the moon and sun components are substantially synchronized.

The Chinese calendar is not the only calendar of this type, but the Hebrew calendar used in Israel and used by the Jews for traditional purposes is also the lunisolar type. However, unlike the complicated Chinese calendar , the Hebrew calendar is relatively easy to process on a computer. This is because it is a calendar based on independent rules far beyond 1000, and there is no need to check any external astronomical data. For example, the length of a month is fixed, and if a leap month is needed, it always appears before the first month of the year. As a result, knowing the date after a certain period or converting between the Jewish date and the Gregorian date is a simple process.

The Chinese calendar is very different. According to IBM, “The leap year of the Chinese calendar is based on astronomical observations and very complex calculations, unlike the Hebrew calendar, where the leap year can be calculated very easily and the intercalary month always appears at the same time of the year. "The leap month is calculated" (http://www-306.ibm.com/software/globalization/topics/locales/calendar_chinese.jsp).

The fundamental problem faced when dealing with the Chinese calendar is that the rules are not independent, the actual astronomical data is more important than any simple approximation (supreme), and everything the rules do It represents what happens when a particular astronomical event occurs. The important astronomical events at issue are the exact time of the conjunction of the sun and the moon (known as the dark moon) and the solar meridian known as the equinox (zhongqi It is a day that accurately crosses a multiple of 30 degrees.

While this seems to be relatively easy, the difficulty that actual astronomical events bring to calendaring is easily underestimated. The data is actually very complex and most people find that the movement of the sun and the moon is actually quite irregular, and the length of the day and the length of the month is one year (from one year to the next Do not know that will change in the years). When performing the calendar calculation, the Chinese calendar (with an average value such as 24 hours a day used in the Western Gregorian calendar, or an alternating 29-day month used for most years in the Hebrew calendar) Always use the true value for such an interval (rather than a 30-day month).

By using the true sun and true moon, the calculations required in advance to calculate the calendar become very complex. This means that no month has a fixed length and a leap month can occur at any point in the year. Since there is no easy way to know either the current month length or the name of the next month, the operations that are natural for users of the Western Gregorian calendar, such as knowing the date six weeks from now, are pre-calculated. It becomes very difficult without access and reference to the calendar table. The same is true when dealing with conversions between Chinese dates and other dates (especially the Gregorian calendar).

In addition, a series of equinoxes every 25800 years, rotation of the Earth's orbit every 110,000 years, and slowing down the Earth's rotation every 2 milliseconds per day, there is always only one astronomical data. Without, it means that the Chinese calendar does not appear repeatedly in connection with other non-astronomical calendars.

In short, there is no way to avoid the use of complex calculations when dealing with any Chinese calendar date.

Since 1949, the Nanjing Purple Mountain Observatory has been responsible for determining dates in the Chinese calendar . However, computers that wish to use the Chinese calendar can use de-facto canonical equations developed by Edward M. Reingold and Nachum Dershowitz. Such calculators can be found in various editions of their book “Calendrical Calculations” (Millenium Edition, Cambridge University Press, August 2001, ISBN: 0521777526).

The standard way of performing calendar calculations with Chinese dates is by using the corresponding Julian date as an intermediate state. The Julian day is a serial number starting from January 1, 4713 BC (E.C.) so as not to be confused with the Julian calendar before the Gregorian calendar, and is widely used especially by astronomers. The Julian Day was invented by the French JJScaliger shortly after the introduction of the Gregorian calendar in 1582 and does not require the use of negative numbers and uniquely references any historical day regardless of the calendar Provide a method.

The Reingold and Dershowitz equations allow conversions from Julian day numbers to any date in any calendar, and from any date in any calendar to Julian day numbers. When applied to the Chinese calendar , these equations allow conversion from and to any other calendar system. These equations also allow arithmetic operations to be performed on Chinese dates, for example, all that is necessary to find the number of days between two arbitrary Chinese dates is to convert them to Julian dates. It only converts and performs arithmetic comparisons.

More information on the complexity of the Chinese calendar is introduced in a paper by Helmer Aslaksen at the Department of Mathematics at the National University of Singapore, which is featured under the title “The Methematics of the Chinese Calendar” and many other papers by the author. With
http://www.math.nus.edu.sg/aslaksen/calendar/chinese.shtml
Can be found.

  Modern computers are known to contain calendar information and data. This is most noticeable for personal information management (PIM) type software such as calendars (Agenda) and scheduling software. Many users of such calculators do not need to convert between different calendar systems, but this is not the case for users operating in multi-cultural environments. According to IBM, "in order to create successful software for global use, you need to be aware of local details ranging from date and time to number formats."

The present invention particularly relates to the general case of a computer whose owner needs to perform the following tasks:
• Perform arithmetic operations on dates in the Chinese calendar , such as determining which day is on the 30th.
• Maintain consistent calendar data in both Chinese and Gregorian calendar formats.
• Maintain consistent calendar data between the Chinese calendar and any other calendar.

The types of such computers have increased in recent years and now include devices such as mobile phones and personal digital assistants (known as PDAs) in addition to desktop computers. Furthermore, as technology is integrated, devices such as game consoles and music players are also including PIM functions. Where the Chinese calendar is the primary calendar or is widely used, when users operate these devices, arithmetic operations on the Chinese calendar date and the Western Gregorian date or Conversion from date is required to fully utilize the PIM function.

However, the Reingold and Dershowitz equations described above need to model the relative positions of the earth, moon and sun, and are known to be inefficient. In addition to the long time to completion, it is necessary to always refer to a large table of astronomy data. Any computer that performs a conversion algorithm between Chinese calendar dates and other calendars is constrained by CPU load and memory requirements. This is known to cause problems even for desktop system software because it requires relatively large computational resources compared to mobile phones and PDAs. For example,
http://homepage.mac.com/rabbel/.cv/rabbel/Public/PDF's%20and%20Doc<1>s/C alendar% 20System% 20Facts% 20V2.pdf-link.pdf
See Denis A. Elliott's "Calendar System Facts" paper found at. Elliot is the author of an Apple Macintosh program called "Intercal" that calculates date conversions between many different calendar systems, showing very clearly that "a huge number of floating point calculations are required". Yes. Elliot specifically mentions the high CPU load of the equation as one of the design constraints.

  Mobile devices such as smartphones and PDAs are large “desktop” and laptop PCs in terms of limited operating memory, limited storage capacity, slower processors and limited battery power. Compared to “fixed” computers, resources are generally limited. However, these owners and users expect a fast sub-second response for most operations, similar to that expected from a desktop PC with no resource constraints.

Using standard methods such as the Reingold and Dershowitz equations for operations on dates in the Chinese calendar , more for these resource-constrained portable devices than they do for fixed devices. Serious problems will arise. Both the intensive calculations that lead to slow operation and the requirements for large amounts of table data result in ease of use and PIM that allows dual-calendar on such resource-constrained devices This is a major obstacle to the wide adoption of the system.

For this reason, there is a need for a processing method for calculation operations related to Chinese calendar data that places little burden on the CPU.

Accordingly, it is an object of the present invention to provide an improved method of handling computer operations on Chinese calendar data that is less CPU intensive, does not involve floating point operations, and does not require a large amount of memory. Thus, the present invention is ideal and particularly suitable for resource-constrained portable devices and provides significant technical benefits when used in such devices. However, as will be apparent from the detailed description below, the present invention also provides technical benefits for "fixed" computers with less resource constraints. None of these “fixed” computers had the fact that a method with a low CPU load on any computer uses a moderate amount of power, is fast to operate and, as a result, is environmentally friendly.

A first aspect of the present invention relates to a calculation method of a computer for converting a Chinese calendar date and a Julian day number within a certain range, and a. The length of the month of each year of the Chinese calendar included in the range; b. If there is a leap month in each year of the Chinese calendar included in the range; c. Storing information of the computer in a memory indicating a Julian day number and at least one set of Chinese calendar date data for a common day in the range; and a central processing unit (CPU) of the computer Converting between the Chinese calendar date and the Julian day number using stored information.

  According to a second aspect of the present invention, there is provided a computer, wherein the calculation is performed according to the method according to the first aspect.

  According to a third aspect of the present invention, there is provided an operating system, wherein a computer is operated according to the method according to the first aspect.

  Embodiments of the present invention are described below with reference to the accompanying drawings by way of example.

FIG. 1 is a diagram showing a process for determining a 29-day month and a 30-day month occurring in an arbitrary Chinese calendar year, and FIG. 2 is a Julian day number and a Chinese calendar date according to the present invention. It is a figure which shows the conversion process between.

First, in order to understand the present invention, it is necessary to explain why lookup tables are not widely used in order to solve the above problems. In a technique where a period of time for a device can be reasonably determined, one of ordinary skill in the art could perform the calculation in advance, instead of performing the calculation quickly with the Reingold and Dershowitz equation, The resulting daily Chinese calendar data is placed in an ordered list held in the device. This makes it possible to find the answer to any calendar operation on the Chinese calendar date using a simple lookup table.

  This type of lookup table is not a viable solution to the problem because the amount of data is too large.

A Chinese calendar date consists of at least five independent date elements:

・ Period (each period is 60 years)
-Year of the cycle-Month of the year-Whether the month is a leap month-Date of the month To store this in the traditional data structure, 5 integers are needed, and many computers are 32-bit Standard lookup tables would need to exceed 20 bytes per day (5 × 32 = 160 integers) or 7 Kbytes per year. The overhead increases rapidly. For example, assume that a device is required to handle dates in years that range from 1980 to 2100 (Gregorian calendar) at a minimum. This 120-year range produces a conversion overhead of about 856 Kbytes of data over 43,830 days. The common size of ROM (read-only memory) in a smartphone or PDA device is 8 megabytes, and obviously a single calendar table occupies over 10% of this valuable and important resource in practice. Not acceptable.

Certainly some optimization of this table data is possible. The data structure can be compressed and extra information can be removed (eg, save the entire cycle when there are a maximum of 3 in a 120 year period). It can store all of the Chinese calendar dates in a single 32-bit integer (at an inefficiency cost when referring to the data), resulting in an overhead of only 80% Will decrease. This gives about 171 Kbytes of data with very little ROM overhead for the 120 year period sample mentioned above.

Although this is a great improvement, in practice, the space in the read-only memory (ROM) of a portable device is very costly. If China on no fixed calendar (non-Chinese fixed calendars) and comparable overhead facts calendar zero, adopting the approach of the table-driven version of the device that can use the functions of the Chinese calendar Inevitably means that you need to have a larger ROM (which leads to increased production costs and boot time for devices using NAND flash technology) or reduced functionality (users feel quality degradation). I will.

  For these reasons, a table-driven efficient approach has not been implemented in resource-constrained portable devices.

However, the present invention reduces the overhead of pre-compiled Chinese calendar information from the original substantially “optimized” overhead of 20 bytes per day to as little as 6 bytes per year. And provide great technical benefits. Thus, for the 120-year period described above, the original required memory of 856 Kbytes is reduced to just 0.7 Kbytes of required memory.

  This reduction of over 99.9% in table overhead is clearly far superior to the previous optimized data compression method that only reduces data overhead by as much as 80% and is a large and cumbersome data table in the device Without the need to include the additional technical benefit of eliminating computationally expensive on-the-fly calculations based on the Reingold and Dershowitz equations. Therefore, the technical performance of the device is greatly improved.

The main idea behind the present invention is to understand what is certain about the Chinese calendar and what is uncertain. Or, in other words, if the starting point is a fixed Chinese calendar date corresponding to a specific Julian date, then for each subsequent day, the Chinese calendar corresponding to that date The date is an attempt to calculate how many days, at what point the calculation results are uncertain, and what information is needed to ensure that the order continues.

Date Chinese calendar that order correspond to any known Julian day and it (i.e., five independent data elements described above relative to that date are well known) if starting from China that contains the date of the Chinese calendar You can see that the first problem is encountered when the end of the calendar month approaches for the first time.

  In this regard, two pieces of information are necessary. First, how many days are there in a month (must be either 29th or 30th), and second, whether the next month is a leap month (in any case). Once this information is available, progress is maintained, you know when the current month ends, and you know the number of days in the next month.

It is worth noting that this also applies to the end of the Chinese calendar year. When the end of any 12 months is reached, if the next month is not a leap month, a Chinese New Year is reached. Thus, the next month (new month) is reset to 1, the leap month indicator is reset, the year is incremented, and finally a decision to determine whether the year has exceeded 60 (the duration of the cycle) If exceeded, the period is increased and the year is reset to 1. FIG. 1 is a diagram showing the length of each month in the Chinese calendar included in the range and, if any, which month of each year in the Chinese calendar included in the range is a leap month. . This information is stored in the computer as a table.

  There are many possible ways to encode this information in the form of an efficient table on a computer. However, the preferred implementation disclosed in this embodiment is designed for Symbian OS (registered trademark) basic software for mobile phones created by Symbian Software Ltd. An example of sample code for implementing the present invention is shown below. Those skilled in the art of programming Symbian OS (registered trademark) basic software will be able to easily understand the purpose and intention of the present invention together with the description of the present invention.

  However, it is to be understood that the implementations and examples provided below are provided as examples only. It is emphasized that the present invention is not intended to be limited only to Symbian OS® basic software or the specific implementations described below. The present invention may be implemented in a variety of ways on many different operating systems and devices, including other types of computers, without departing from the scope of the invention.

The embodiment of the present invention described below provides information on which month of the year has 29 days and which month has 30 days, for each year a simple bitmap 16-bit integer (bit-mapped 16- bit integer). Note that there are either 12 months in a normal year or 13 months in a leap year (only one leap month per solar year is possible). This embodiment identifies the range of computers in the year of the Gregorian calendar and shows implementation for 1980-2100 as it is easily related to the above-described prior art solution that consumes a lot of resources. The sample code shows an array of these integers in the CALCONDATA.CPP file called TCalconData :: iCalConDataMonth. From this arrangement, it can be seen that there is a 16-bit integer for each of the 120 years in the date range under consideration. The beginning of the Gregorian calendar 1980 is located during 55 years of the first period of the Chinese calendar in this 120-year period. This explains the 0-55 comment attached to the first integer in the array, making the progress easy to understand. The beginning of the Gregorian calendar 1980 is the last of the 55th year of the Chinese calendar, and the 55th year of the Chinese calendar is not the year that begins immediately after the start of the 1980 Gregorian calendar. Since the Chinese New Year is always January or February, the start of the Gregorian calendar 1980 is either the last month of the Chinese calendar 55 or the penultimate month. It is also necessary to know whether the Chinese calendar year 55 is a leap year, whether the current month is a leap month, and whether there are 29 or 30 days remaining in the year. Therefore, the information attached to the Gregorian calendar 1980 must also refer to the year of the Chinese calendar that began in 1979 of the Gregorian calendar.

The first integer in TCalconData :: iCalConDataMonth is 38608 (corresponding to the 16-bit binary array 1001011011010000), which holds information for the Chinese calendar 55 years. In this example of the invention, the binary “1” bit in this sequence indicates a 30-day month and the binary “0” bit indicates a 29-day month. Thus, this binary array, and therefore the integer, has 30 days at the beginning of the 55th year of the Chinese calendar , so the first, fourth, sixth, seventh, ninth, tenth and twelfth are the new months, and this year Indicates that there are 29 days in the remaining month. The second integer in TCalconData :: iCalConDataMonth is 38320, which holds information for the Chinese calendar year 56, starting with the Gregorian calendar 1980, and this integer corresponds to the binary array 1001010110110000. Therefore, this integer has 30 days for the first, fourth, sixth, eighth, ninth, eleventh and twelfth months from the beginning of the Chinese calendar year 56, and the remaining months of this year are 29 days. It shows that there is.

  The second array in the CALCONDATA.CPP file is called TCalconData :: iCalConDataYear and consists of an array of 32-bit integers. On the other hand, there is an integer for each year, and the comments shown in the array make it clear that they match the data for the previous array. Each integer provides more detailed information for each year. Each integer also tells when each year begins, whether there is a leap month in that year, and if so, in which month.

The first integer in this array is 1881492094 and gives information for the Chinese calendar 55, the beginning of the current Gregorian calendar 1980. The least significant bit 28 of this 32-bit integer holds the Julian date corresponding to the beginning of the Chinese calendar year 55.

1881492094 corresponds to the binary array 01110000001001010100101001111110, and the binary number 000001001010100101001111110 provides this information. These least significant bits 27 correspond to the Julian date 2443902. Converting from a Julian date to a Gregorian date is very simple and does not involve computational costs. Such a conversion indicates that the Julian day 2443902 corresponds to the Gregorian calendar January 28, 1979, which is the New Year date of the Chinese calendar 55.

The most significant 4 bits of the 32-bit integer corresponding to 1881492094 is 0111, which corresponds to 7. This information indicates which month (if any) of the Chinese New Year starting on January 28, 1979 is a leap month. In the first year of the Chinese calendar , there is only one leap month. Therefore, in this case, it is understood that the Chinese calendar year 55 is a leap year, and the seventh month of the year is a leap month. Note that the seventh month of the year is actually leap month 6, and the non-leap month 7 is actually the eighth month of the year. The second integer in the array is 2444286, which corresponds to the binary number sequence 00000000001001010100101111111110. In this sequence, the most significant 4 bits are 0000, which corresponds to zero. This means that the Chinese calendar year 56 does not include a leap month and is therefore not a leap year. The least significant bit 28 means that it was a Julian day 2444286 corresponding to February 29, 1980, and thus the New Year of the Chinese calendar 56 years.

The CALCONDATA.H file provides all the other data necessary to interpret the Chinese calendar data for the period in question and gives the boundaries of the data range involved (Julius date 2444240, January 1980) 1st to Jul. 31st, 2100, which is Julius date 2488434), and the first Chinese New Year in the 120-year period under consideration is 56-year Chinese , and the end of this 120-year period. The Chinese New Year is the 57th year of the Chinese calendar , and this 120-year period begins at period 79, reporting that the data spans the entire 122-year range of the Chinese calendar .

  Data provided to CALCONDATA.CPP and CALCONDATA.H can be created in advance and used to build a read-only memory (ROM) of a portable computer. How these data are created is not critical to the present invention. These can be calculated from the Reingold and Dershowitz equations. Data from the Nanjing Purple Gold Mine Observatory or other published calendars will also suffice.

The above disclosure is considered to fully explain how these files can be used effectively in PIM-type applications for computers, with regard to the underlying data and theoretical organization that provides that behavior. . Thus, one skilled in the art can easily implement the present invention to provide a technical alternative to the Reingold and Dershowitz equations, thereby reducing computer resources and conversion time. Can perform high-speed and high-performance conversion between Julian dates and Chinese calendar dates.

For any Chinese calendar date in the range of dates represented in the table, you can go directly to file table entry for the exact Chinese year , the length of all month days and any applicable leap month With the above data, you can directly check the Julian Day of the New Year for the Chinese calendar year. Therefore, to determine the Julian date and therefore the Gregorian date corresponding to any Chinese calendar date, a relatively small number of relatively simple four arithmetic operations that can be easily and quickly performed by a computer are required. To do.

For any Julian date in that date range, you can go directly to the table entry containing the Chinese New Year just before the Julian date, and the length of the month and any relevant leap month information will be looked up once Finding an accurate Chinese calendar date is also a relatively simple four arithmetic operation that can be performed quickly without any special difficulties.

  Also, for completeness, the example of the invention shown below also provides a portion of a sample program file. CHINESEUSINGTABLE.CPP is a work program written for Symbian OS (registered trademark) basic software, including procedures for handling data in tables provided as samples to show how they can be used. Part of the acquired code is included.

One skilled in the art will readily recognize that other implementations and further optimizations are possible. In particular, the condition of matching the Julian date for each New Year in the Chinese calendar is not necessarily required, in fact, the length of the month given only by the date of the Chinese calendar and the date of the same day on which the Julian date is known and These can be calculated arithmetically from leap month data.

This optional optimization, along with further array compression, allows the overhead for each additional Chinese year within the date range to be 6 bytes per year (as used in the above embodiment). Or 48 bits) to at least 17 bits per year, allowing further resource savings from a memory perspective. However, there is some additional computational cost when decompressing this type of bit array, and this type of implementation also results in operations that are dated away from a given point in time and closer to that point in time It will take time to complete the operation by date.

以下のテーブルは、グレゴリオ暦１９８０年〜２１００年に対する付加的なカレンダー情報を示している。

これらは、一連の有用なカレンダー分類を作り上げるためにテーブルがどのように使用されるかを示すコードの断片である。

図２は、ユリウス日の番号と中国暦の日付との間で変換を行うために用いられる処理をまとめたフローチャートを示す図である。 A hybrid with multiple simultaneous time points that does not appear as often as every year is clearly possible. The choice of trade-off for any device produced by the present invention may be left to the designer, but the present invention as defined in the appended claims applies to all such implementations. And is not limited to the preferred embodiments described above. The following example provides a main lookup table for the Gregorian calendar 1980-2100. This table includes a bitmap array representing the length of the month followed by a bitmap array, representing any leap month and Julian day of the Chinese New Year.

The following table shows additional calendar information for the Gregorian calendar 1980-2100.

These are code snippets that show how tables are used to create a series of useful calendar categories.

FIG. 2 is a flowchart summarizing the processing used to convert between the Julian day number and the Chinese calendar date.

It will be appreciated from the above description and specific examples that the present invention provides significant technical benefits over current processes that provide Chinese calendar functionality. The present invention includes the following.・ A method that uses sufficient functions of the Chinese calendar that operates at high speed even on a computer with restricted resources over a specific year number ・ High efficiency of calculation resources such as memory and CPU usage Costly and does not include very long floating point number operations Reduced memory usage: less than 0.01% of comparable current table lookup methods Computers with sufficient PIM capabilities are in China For those working in countries where the calendar is widely used, the power of the equipment that is more easily supplied and implemented is significantly reduced, which has an environmental advantage in terms of natural resources and implements it Although the present invention has been described with reference to particular embodiments, modifications may be made without departing from the scope of the invention as defined by the appended claims. You will see that it can be done.

It is a figure which shows the process which determines the month of 29 days and the month of 30 days which generate | occur | produce in arbitrary Chinese calendar years. It is a figure which shows the conversion process between the Julian day number and Chinese calendar date concerning this invention.