Re: [Sedate] Calendar systems

>
> My point was not that that's what we understand but that it needs to be
> stated explicitly - because it's guaranteed that some people will
> understand differently.

Agreed.

On Thu, Dec 9, 2021 at 11:41 AM Michael Douglass <mikeadouglass@gmail.com>
wrote:

>
> On 12/9/21 14:19, Justin Grant wrote:
>
>
> I would indeed understand the wording in the
>> given example as saying the given date is a perfectly usual ISO 8601
>> date in the Gregorian calendar, but encouraging the receiving software
>> to *display* it using the Hebrew calendar's description of the exact
>> same moment.  Software lacking support for that calendar would be
>> entirely within its rights to ignore the annotation, IIUC.
>
>
> This matches our expectations on the JavaScript Temporal side. It's a hint
> for the receiving application to know about the calendar preference of the
> sending user, e.g. for display.
>
> My point was not that that's what we understand but that it needs to be
> stated explicitly - because it's guaranteed that some people will
> understand differently.
>
>
> On Tue, Dec 7, 2021 at 9:28 AM Edward Welbourne <edward.welbourne@qt.io>
> wrote:
>
>> Michael Douglass (7 December 2021 17:51) wrote:
>> > Reading through the draft I can't tell what the intent of this is:
>>
>>   1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]
>>
>>   Figure 5: Projecting to the Hebrew calendar
>>
>>   Figure 5 represents the exact same instant, but it informs
>>   calendar-aware implementations that they should project it to the
>>   Hebrew calendar.
>>
>> > Is it a hint that it might be appropriate to display the Hebrew date -
>> > for example a website listing Jewish religious festivals or it it
>> > something else.
>> >
>> > I assume we're not trying to say the date is actually a Hebrew
>> > calendar date? Or are we?
>>
>> I'm a total n00b to this list, but (not entirely unfamiliar with
>> calendars and date-times) I would indeed understand the wording in the
>> given example as saying the given date is a perfectly usual ISO 8601
>> date in the Gregorian calendar, but encouraging the receiving software
>> to *display* it using the Hebrew calendar's description of the exact
>> same moment.  Software lacking support for that calendar would be
>> entirely within its rights to ignore the annotation, IIUC.
>>
>> > I'm not even sure it helps with time/date calculations - if I as a
>> > non-Hebrew calendar person wants to set an alarm 1 month ahead I
>> > probably mean a Gregorian 1 month - but perhaps I'm wanting to know
>> > the Hebrew 1 month ahead - but I might want that even if the date is
>> > Gregorian.
>>
>> hmm ... well, I guess the receiving software would display an event as
>> starting at the given time; and it's up to the UI to, hopefully, let the
>> user switch between calendars when selecting when to set an alarm ahead
>> of it.  OTOH, setting alarms a month ahead probably isn't high on the UI
>> designer's list of priorities.
>>
>> And - speaking of being a n00b - Hi, I'm one of the Qt project's
>> developers, I take particular care of the l10n, date, time, time-zone
>> and calendar parts of the open source / free Qt framework, and I'm
>> paying attention because I'll probably want to add support for whatever
>> format you all end up deciding on,
>>
>>         Eddy.
>>
>> --
>> Sedate mailing list
>> Sedate@ietf.org
>> https://www.ietf.org/mailman/listinfo/sedate
>>
>