Print

Print


The suggestion, then, is that 21, 22, 23, 24 respectively mean "first
season", "second season", "third season", "fourth season", where season is
not  defined, other than to say something like "it may correspond to
winter/spring/summer/fall (or spring/summer/fall/winter) in the north, or
summer/fall/winter/spring (or fall/winter/spring/summer) in the south, or it
may correspond to quarters".

In which case we do not need to accommodate a geographic-location field. 

Is that your suggestion, Ed?

--Ray

> -----Original Message-----
> From: Discussion of the Developing Date/Time Standards
> [mailto:[log in to unmask]] On Behalf Of Edward C. Zimmermann
> Sent: Thursday, November 18, 2010 5:04 PM
> To: [log in to unmask]
> Subject: Re: [DATETIME] season
> 
> On Thu, 18 Nov 2010 15:30:11 -0500, Denenberg, Ray wrote
> 
> > The main issue here is maintaining sortability, so we have to choose
> > the delimiting characters carefully (which I haven't done yet).
> 
> How would I sort Summer in Europe?
> We have, for example,  1st of May. 1st of June and 21th June all as
> starting dates.. To maintain sort, I'd imagine, one must assign country
> names on the basis of their starting dates for Summer?
> 
> Personally, I think we'd be better off not talking about Summer etc.
> but seasons in the calendar year and their types: meterological,
> astronomical and perhaps either a misc case or adjustment. This would
> define the start and end points.
> So instead of using names such as Summer (and the suggested coding is
> just
> that) I'd simply label the seasons 21,22,23,24 BUT use them as the
> count in the calendar year. 21 would not always be Spring but it would
> always be the first season of the calendar year--- which coincides with
> Spring in the Northern Hemisphere. In the South then 21 would be Fall.
> The advantage would be that 2000-21-1 (for year 2000, 1st meterological
> season) in Australia could be compared in a chronological sort with
> 2000-21-1 in Denmark.
> The problem, of course, would be 24 as it crosses the boundary and a
> date such as (in the North) Winter 2011 might be the same as Winter
> 2010---- similarly Summer in the South. I see no solution other than
> perhaps the requirement that last of a given year must the preceding
> season of the year (Autumn in the US) or be corrected (year-1).
> 
> In North American
> Spring 2010
> Summer 2010
> Autumn 2010
> Winter 2011 -> Winter 2010/2011
> Spring 2011
> 
> Not knowing the date of receipt of journals one can't fix these.. but
> just accept that they might not always be accurate (can't distinguish a
> Winter 2010 publication between Winter 2009/2010 and Winter 2010/2011)
> 
> 
> Edward C. Zimmermann, NONMONOTONIC LAB
> Basis Systeme netzwerk, Munich Ges. des buergerl. Rechts Office Leo
> (R&D):
>   Leopoldstrasse 53-55, D-80802 Munich,
>   Federal Republic of Germany
> http://www.nonmonotonic.net
> Umsatz-St-ID: DE130492967