Representation of season was recently brought up again. In this case the question is whether hemisphere needs to be represented, see below.
My understanding is that the use case presented to us is satisfied, by using 21, 22, 23, 24 in place of month, to represent season. While not a complete solution it seems to meet the concrete needs that were presented, even if it leaves unsolved some issues regarding sorting, when a season starts, etc.
There were other, less specific "potential" use cases presented, which could be satisfied by appending a qualifier to the season.
So
'2001-21' means "Spring, 2001"
and
'2001-21q<xxx>' "Spring, 2001 qualified" where <xxx> is the qualifier.
The qualifier could be a geographic location, but unless someone takes the initiative to try to develop this qualifier, it's specification won't be included in the spec.
This is where we ended up with this discussion, and as far as I knew everyone was satisfied. Unless someone has a use case that this doesn't satisfy, I don't see a need to re-open discussion on this.
Does anyone think this needs further discussion?
--Ray
From: Saašha Metsärantala
> Sent: Monday, February 14, 2011 9:17 AM
> Subject: Re: [DATETIME] Revised spec
> > hemisphere seasons represented separately
> I consider there are two different (and related) questions here. One of
> them is whether we need to specify if (for example) "summer 2011 in the
> southern hemispere" or "winter 2011 in the northern hemispere" refer to
> the beginning or the end of the year 2011. The other question is
> whether we need to sort these dates chronologically. Let's assume that
> something occurs in automn / fall 2011 and something else occurs during
> the spring of 2011; do we need to be able to sort these events
> chronologically? If we need that, then we would need to specify the
> hemispere where each of these events occurs.
|