W3C home > Mailing lists > Public > public-i18n-ws@w3.org > December 2003

Re: calendar *dependent* events scenarii

From: Mike McKenna <mgm@globalisation.org>
Date: Tue, 02 Dec 2003 16:27:54 -0800
Message-ID: <3FCD2E0A.4050501@globalisation.org>
To: public-i18n-ws@w3.org
Here's a couple of fun examples from the web:

http://www.tondering.dk/claus/calendar.html

    This is a calendar FAQ. Its purpose is to give an overview of the
    Christian, Hebrew, Persian, and Islamic calendars in common use. It
    will provide a historical background for the Christian calendar,
    plus an overview of the French Revolutionary calendar, the Maya
    calendar, and the Chinese calendar.
    (excellent resource!  Especially interesting is the catalog of dates
    when various countries adopted the Gregorian Calendar)

http://www.cl.cam.ac.uk/~mgk25/iso-time.html

    An interesting link about time and timnezones.

http://www.ignca.nic.in/ks_40008.htm

    (a problem with passports ...)
    According to the Gazeteer of Chaling Country, Tan Yun-shan was born
    at the Shen hour (1500-1700 hours) on the 5th of the 9th moon of the
    Wuxu year of Emperor Guangxu's Era of the Manchu Dynasty, i.e. 1898.
    Tan Yun-shan was a man who was keen to embrace modern trends. He
    recorded the birth of all his children according to the solar
    calendar. This created problems for his second son, Tan Zheng, when
    he applied for passport to come to India in the 1970s. The Hunan
    passport office refused to believe that his date of birth was
    recorded in the solar calendar, as he was born in 1932. It promptly
    converted his solar birthday into another solar birthday. Few modern
    Chinese could imagine that Tan Yun-shan did this in the early
    decades of the century to his own birthday. One year, this 5th of
    the 9th moon coincided with the 10th of October which was the
    national day of the Republic of China. This gave him an occasion to
    switch calendar. Henceforth, everyone easily remembered that he was
    born on the "Double 10th Festival", forgetting the original date
    recorded in the lunar calendar.

http://www.archives.gov/facilities/ca/san_francisco/holdings_guide_04.html
          Geneology and immigration documents - example would be 
services that provide digital versions of documentation

http://www.vn-tourism.com/english/what.htm

    *Kate Festival *

    This is the largest and the most joyful festival in Ninh Thuan and
    Binh Thuan provinces, where live many Cham people. The ceremony
    takes place at Poklong Giarai Tower, Po Rome Tower, Po Nagar Tower
    Temple, from Sept.25th to Oct. 10th (on the 1st of July according to
    the Cham calendar - corresponding to August or September by the
    Lunar calendar).  ....

Cheers,

       Mike____

Mark Davis wrote:

>Yes, it is tricky.
>
>  
>
>>Alas xsd:date allows a timezone identifier...
>>    
>>
>
>An (optional) timezone identifier is actually reasonable. Stating that it is
>July 12, 1999 GMT does convey different information than just July 12, 1999
>(undetermined zone), or than July 12, 1999 Pacific Time.
>
>Note that July 12, 1999 08:00 Pacific Time is very different than July 12, 1999
>08:00 GMT-08:00. You see that when you start to set up a repeating meeting, such
>as in calendar software. If we meet every month on the 12th at 08:00 PT, that
>will be sometimes 8:00 GMT-08:00 and sometimes 07:00 GMT-08:00. And in most
>cases, PT is what people want instead of GMT-08:00.
>
>Mark
>__________________________________
>http://www.macchiato.com
>► शिष्यादिच्छेत्पराजयम् ◄
>
>----- Original Message ----- 
>From: "Addison Phillips [wM]" <aphillips@webmethods.com>
>To: "Mark Davis" <mark.davis@jtcsv.com>; <andrea.vine@Sun.COM>;
><public-i18n-ws@w3.org>
>Sent: Tue, 2003 Nov 25 13:02
>Subject: RE: calendar *dependent* events scenarii
>
>
>
>XML Schema does a lackluster job of explaing any of this.
>
>I probably wouldn't use ranges for a calendric (non-point) date value. I'd
>probably use the 'xsd:date' type in preference to a 'xsd:dateTime', e.g.
>'2003-11-25' instead of '2003-11-25T00:00:00Z'. The point then is that you
>should not interpret a calendric date using a time zone (either your local one
>or some other value). Alas xsd:date allows a timezone identifier...
>
>This is contrary to most date arithmetic in Java and other programming
>languages, where dates are, as you say, generally just of the point type and you
>must interpolate the 'right value' from a specific date object or apply the
>correct usage based on implementation decisions. There is some question, for
>example, of whether midnight GMT or noon GMT is a better 'default' value for a
>date object representing a 'calendric value' like this (since noon actually
>falls during the day for nearly all time zones, whereas midnight doesn't affect
>the bits in the underlying long integer value).
>
>In any case, the mere fact that we're having this discussion points up the fact
>that most developers have, in my experience, a lot of trouble with date,
>datetime, timezone, and related event-driven issues: this is a neglected topic
>of discussion. It's nice to explain some of it.
>
>Addison
>
>Addison P. Phillips
>Director, Globalization Architecture
>webMethods | Delivering Global Business Visibility
>http://www.webMethods.com
>Chair, W3C Internationalization (I18N) Working Group
>Chair, W3C-I18N-WG, Web Services Task Force
>http://www.w3.org/International
>
>Internationalization is an architecture.
>It is not a feature.
>
>  
>
>>-----Original Message-----
>>From: Mark Davis [mailto:mark.davis@jtcsv.com]
>>Sent: mardi 25 novembre 2003 12:44
>>To: aphillips@webmethods.com; andrea.vine@Sun.COM; public-i18n-ws@w3.org
>>Subject: Re: calendar *dependent* events scenarii
>>
>>
>>The ranges are funny, and XMLSchema and ISO 8601 sorta punted.
>>The problem is
>>that when someone implicitly treats a date as translateable to a
>>range that it
>>gets a bit gummy.
>>
>>When someone typically refers to a date, e.g. July 12, 1962, even
>>when fully
>>specified (GMT), they don't really mean all points in time
>>between July 12, 1962
>>00:00:00 GMT and July 13, 1962 00:00:00 GMT (half-open interval);
>>they typically
>>mean that some event transpired during that time, e.g. that the
>>event overlapped
>>with the full range. Thus the fact that Joe was born on that date
>>means that
>>there was some time during that date when he was born, not that
>>he was being
>>born through the entire period.
>>
>>Now in normal usage, this is not much of an issue, simply because
>>the dates are
>>uninterpreted. But when one starts to use the arithmetic
>>functions on them or
>>translate timezones, it starts to give funny results. If Joe was
>>born at 01:00
>>am that night, then he was born on July 11, 1962 (in pacific
>>time); he wasn't
>>born "on" July 11, 1932 17:00:00 through July 12, 1962 17:00:00,
>>Pacific Time,
>>although he was certainly born at some time during that interval.
>>
>>Anyway, that was all a digression. Java doesn't really represent
>>this either,
>>since a Date (and a Calendar) always refers to a specific point
>>in time, not a
>>date with an undetermined time.
>>
>>In ICU4J we do have classes that represent 'indirect' times, like the 2nd
>>Tuesday in the month, or the 2nd to the last Tuesday in the
>>month. If you want
>>to represent something like the observed Columbus day, which is
>>formally on X
>>day, but is observed on the closest Friday or Monday, then you
>>need something
>>like this. But that is a way, if you will, of computing the actual day. I
>>suspect the example you use would just serve up actual days.
>>
>>Mark
>>__________________________________
>>http://www.macchiato.com
>>► शिष्यादिच्छेत्पराजयम् ◄
>>
>>----- Original Message ----- 
>>From: "Addison Phillips [wM]" <aphillips@webmethods.com>
>>To: "Mark Davis" <mark.davis@jtcsv.com>; <andrea.vine@Sun.COM>;
>><public-i18n-ws@w3.org>
>>Sent: Tue, 2003 Nov 25 12:22
>>Subject: RE: calendar *dependent* events scenarii
>>
>>
>>Hi Mark,
>>
>>The point of the scenario isn't the usefulness index, although we
>>would like for
>>the service described to have some utility (and not be a
>>meaningless example).
>>The point is actually to draw a distinction between values that are
>>point-moments in time (January 3, 1956 at 10:23:47 PM Pacific Standard
>>Time---what in Java you'd call a java.util.Date) and "calendric"
>>moments ("the
>>Fourth of July", people's birthdate, etc--what in Java you might use a
>>java.util.Calendar to represent)
>>
>>These require slightly different data types in XML Schema and, of course,
>>different handling in code.
>>
>>But state holidays in Utah are a good example too.
>>
>>Addison
>>
>>    
>>
>>>I don't know that the calendar scenario is actually that useful;
>>>most OSs have a
>>>variety of calendars already. What would be a more compelling
>>>example would be a
>>>server for 'business holidays', since those are not generally
>>>supported, and
>>>vary by country and even by smaller units: states/provinces, even
>>>cities; and
>>>may need updated frequently.
>>>
>>>E.g. get me the state holidays in Utah.
>>>
>>>Mark
>>>__________________________________
>>>http://www.macchiato.com
>>>► शिष्यादिच्छेत्पराजयम् ◄
>>>
>>>----- Original Message ----- 
>>>From: "Addison Phillips [wM]" <aphillips@webmethods.com>
>>>To: <andrea.vine@Sun.COM>; <public-i18n-ws@w3.org>
>>>Sent: Mon, 2003 Nov 24 21:25
>>>Subject: RE: calendar *dependent* events scenarii
>>>
>>>
>>>      
>>>
>>>>Hi Andrea,
>>>>
>>>>Great stuff. Some suggestions on the intro and first scenario below.
>>>>
>>>>Addison
>>>>
>>>>
>>>>        
>>>>
>>>>>Scenario I-0?? Calendar-dependent events
>>>>>
>>>>>A Web service is set up to calculate a calendar date and send
>>>>>          
>>>>>
>>>it back to
>>>      
>>>
>>>>>the requester.  The date is calendar-dependent but is not
>>>>>          
>>>>>
>>>associated with
>>>      
>>>
>>>>>a particular locale or timezone.  The service may need to take in
>>>>>information such as the calendar type, year, and related descriptive
>>>>>information.
>>>>>
>>>>>          
>>>>>
>>>>Perhaps "The value returned represents a specific date on the
>>>>        
>>>>
>>>calendar, not
>>>      
>>>
>>>>a timestamp value as might be associated with a particular locale or
>>>>timezone."??
>>>>
>>>>
>>>>        
>>>>
>>>>>Scenario A:  A service calculates the date for Easter, Passover, or
>>>>>Ramadan for any given year in a specified calendar type.  All these
>>>>>holidays are strictly calendar-dependent; they are
>>>>>          
>>>>>
>>calculated based on
>>    
>>
>>>>>certain calendar and lunar events, as well as historical tables.
>>>>>          
>>>>>
>>>>I don't think the intro to Scenario A quite captures it. I
>>>>        
>>>>
>>>think we need to
>>>      
>>>
>>>>draw the distinction with fixed-date events. Maybe:
>>>>
>>>>A service calculates the date for Easter, Passover, or Ramadan
>>>>        
>>>>
>>>for any given
>>>      
>>>
>>>>year in a specified calendar type. These religious holidays are
>>>>        
>>>>
>>>partly based
>>>      
>>>
>>>>on astronomical events (such as lunar phases) as well as
>>>>        
>>>>
>>>historical tables
>>>      
>>>
>>>>and not strictly calendar dependent (in the way that many
>>>>        
>>>>
>>>secular holidays,
>>>      
>>>
>>>>such as various national independence days or leader's
>>>>        
>>>>
>>birthdays are) or
>>    
>>
>>>>predictable (third Thursday in November, etc.). Thus the need
>>>>        
>>>>
>>>for a service
>>>      
>>>
>>>>to calculate the date might be necessary. // continue with...
>>>>        
>>>>
>>"The SOAP
>>    
>>
>>>>request..."
>>>>
>>>>        
>>>>
>>>>>The
>>>>>SOAP request would contain a holiday, a year, and a parameter
>>>>>          
>>>>>
>>>indicating
>>>      
>>>
>>>>>the calendar type, e.g. "Gregorian".  In addition, some
>>>>>          
>>>>>
>>other data may
>>    
>>
>>>>>be required, such as for Easter there may be a parameter specifying
>>>>>"Orthodox" or "Western".  The Web service would in turn
>>>>>          
>>>>>
>>calculate the
>>    
>>
>>>>>appropriate date and send a message back to the requester with the
>>>>>calculated date.  It may seem as though the calendar type
>>>>>          
>>>>>
>>is a part of
>>    
>>
>>>>>the locale information, but locale information is typically
>>>>>          
>>>>>
>>associated
>>    
>>
>>>>>with the end user, and there's far more information in a
>>>>>          
>>>>>
>>>locale than is
>>>      
>>>
>>>>>needed. In this case, the calendar type is irrelevant to the locale,
>>>>>since the requester may be looking for information unrelated to user
>>>>>preferences or system settings.
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>        
>>>>
>
>
>
>
>  
>
Received on Tuesday, 2 December 2003 19:28:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:38 UTC