[Sedate] projection vs encoding // draft-ietf-sedate-datetime-extended-03 Calendar

["Edward C. Zimmermann" <[e-mail]>]

Hi,


Since I want to extend EDTF to calendars, I'm looking at a homogenization amongst standards.. (which could
one day upstream go into a new revision of ISO-8601)

Looking at the IETF draft I have some comments...


In the draft we have (without much comment)

  1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]

                 Figure 4: Projecting to the Hebrew calendar

    Figure 4 represents the exact same instant, but it informs calendar-
    aware implementations that they should project it to the Hebrew
    calendar.

This makes no sense as an implementation (parser etc.) should be typically free to handle any internal
transformation it wishes. Given the simple math many will internalize as something based roughly around
a Julian calendar.

Fliegel, H. F., and Van Flandern, T. C., "A Machine Algorithm for  Processing Calendar Dates,"
Communications of the Association of  Computing Machines, vol. 11 (1968), p. 657.


To specify an internal representation ("projection") in an expression (e.g. encoding) is quite counter-intuitive.

An implementation that wishes to internally convert to a Lunar or Lunar/Solar (like the Hebrew) calendar would,
of course, need both the geo location (Los Angeles here being used not just for information but literally required
for the transformation) and time to determine if the timestamp is before or after sunset. In this regard I'd have
to point out that there are a number of different models and that is, again, up to the implementation.

Instead, however, it would definitely make sense to specify the **encoding** of the timestamp, viz. its
selected calendar.

The above is just a description of how to perhaps contextualize the ISO date and time specified.

1996-12-19T16:39:57-08:00[America/Los_Angeles]
Specifies that the following date is encoded in Hebrew.
Note we have multiple Hebrew calendars based on the differing ideas of when the day starts after sunset
(the concept of Bein HaShmashot)... but I'm getting too deep into details here..

If we count the 12th month as the month of Adar, in the ISO calendar this may convert to 1 March -1764
(in the 8601:2019 standard we now have negative years). What we need to know is where.. here Los Angeles..
GPS  34.052235, -118.243683 which we could use to determine sundown, when know if its indeed 1 March or
the day before..

Keeping to the encoding.. we need to understand that we have multiple models for time in the Hebrew
calendars..  One using T := 3600 subunits per hour, e.g. seconds but a more common one based on 1024 sub units
e.g. 1 degree of rotation. Roughly 3 1/3 seconds.

I would argue for in addition to the ISO-8691 T which is used as the default.. we add a B extended to define
the cycle of encoding as 1024. I am not familiar with any other sub-minute encodings but we could extend it.


To make things even more complicated we have 24 hour time clocks aligned with the ISO but we also have a clock
in the Hebrew (and some others) with 12 hours day and 12 hours night for the 24 hour cycle. The clock starts
in this model at sunrise.	

With the Islamic (Hirji) calendar it is equally as complex. We have some places where the 24 hour clock starts
at maghrib (just "after" sunset).

With many calendars lacking a GPS coordinate in the encoding models we need to assume some "center". For the
Hebrew this could be, for example, the Kotel /Har haBayīt.

In addition I'd toss the place name and instead use a GPS encoding with an optional informational human oriented
expression of location that need not demand a controlled vocabulary (or registration).

For the GPS encoding I'd suggest something as simple as the Maidenhead Locator System:
  https://en.wikipedia.org/wiki/Maidenhead_Locator_System
(but there are others)

----

Edward C. Zimmermann
http://www.nonmonotonic.net