FW: [Koha-devel] Re: non-simple publication years?

[Anthony W. Youngman]

And you have to watch out with Western dates too ...

Take Pepys diary. While you would probably have no desire to store these
dates, those between January and March every year belong to which year? (New
Year was March 25th).

The only safe way to store these things (if you do want to future-proof it
in any way) is to store all dates as a Julian/Conversion pair.

Julian as in an explicit offset from a fixed date (eg the Unix ?1/1/1970?
day 1) and a conversion that says Julian/Gregorian/Republic/Japanese
Imperial/whatever. Not a trivial conversion if you haven't planned that in
in your original design :-(

Cheers,
Wol

-----Original Message-----
From: news-misc at ada.dhs.org [mailto:news-misc at ada.dhs.org] 
Sent: 10 December 2002 04:55
To: koha-devel at lists.sourceforge.net
Subject: [Koha-devel] Re: non-simple publication years?


In article <200212042234.54111.fmmarzoa at gmx.net>, Francisco
M. Marzoa Alonso <fmmarzoa at gmx.net> wrote:

>I think that's a matter of representation, so database
>structure could be as is (with that sort integer) and scripts
>could be modified to support different dating standards simply
>making conversions. Although I think this does need change some
>scripts, not just templates, because as it seems to be your
>case, sometimes the matter is an input value on a form.
>
>The same is applicable to date formats on different countries
>or using different standards. (i.e. some countries use
>DD-MM-AAAA while others use MM-DD-AAAA). I think there may be
>some kind of support for this in koha so it should be not very
>difficult to adapt it for your chinesse years, but I'm not
>sure.

I guess then this would be something for Koha 3.0 :-)

In our library not all dates are in "Chinese" format ("Republic"
years, now used only in the ROC); we only lists the Republic
dates if the book lists them.

I wondered whether this is just a peculiarity
of our library, so I went to another library
(http://mdx.tpml.edu.tw/v2.3/tables/01a.htm) and see how they
do it. They do it just the same; not all books are listed in
Republic dates, just some (presumably also just the books which
lists dates in this format).

So, sticking with the principle that Koha should not dictate how
users use the system, we cannot go the conversion route :-)

Also, if we go a conversion route, it will also be quite
complicated, because one A.D. year may correspond to two or
more years in the "foreign" calendar. (For example, the Chinese
and Japanese dates are based on the reign of kings, and the
king has the say what the new epoch is called (so we can never
"future-proof" Koha if we go the conversion route); so one A.D.
year can correspond to two Japanese years if, e.g., they get a
new Japanese emperor :-) It could get messier if the foreign
calendar system is not solar :-( [not the case with modern
Chinese and Japanese dates, though]


-- 
Ambrose Li  <a.c.li at ieee.org>
http://ada.dhs.org/~acli/cmcc/  http://www.cccgt.org/

DRM is theft - We are the stakeholders


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/koha-devel


This transmission is intended for the named recipient only. It may contain
private and confidential information. If this has come to you in error you
must not act on anything disclosed in it, nor must you copy it, modify it,
disseminate it in any way, or show it to anyone. Please e-mail the sender to
inform us of the transmission error or telephone ECA International
immediately and delete the e-mail from your information system.
Telephone numbers for ECA International offices are: Sydney +61 (0)2 9911
7799, Hong Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New York +1
212 582 2333.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20021210/2a505e8a/attachment-0002.htm>