Remove UTC requirement from navDate

[azaroth42]

As the value of navDate is just the date, there is no space for an additional label for presenting to the user. If the date is required to be UTC, then the label will look very wrong to the user when it crosses the dateline. For example, a datetime in France of 00:30 will be 23:30 the previous day in UTC, and vice versa for US timezones.

Proposal: Allow any timezone to be used, defaulting to UTC if not supplied.

[tomcrane]

:+1: to this - the displayed dates for navigation of newspapers in the UV suffer this problem.

[mikeapp]

👍

[zimeon]

:+1: to allowing any timezone

I think we need a few words saying something about flexibility for how clients may handle this. In the case of display of a dateline for set of data with consistent timezone, it is likely preferable to use the timezone specified in order to understand/present the date (e.g. the 00:30 in France example above).

According to https://www.w3.org/TR/xmlschema-2/#dateTime -- the timezone of xsd:dateTime is simply unknown if not specified. I agree that we need to say that in order to support mixing of data either 1) the value will be treated as UTC is no timezone is specified, or 2) a timezone must be specified. Option 1 has the advantage that we then accept any valid xsd:dateTime as valid.

[jpstroop]

I hesitate to get away from UTC as I think it just kicks a common problem downstream. What about navLabel instead? If the entire Solr community can live with UTC, I suspect IIIF can as well.

[tomcrane]

To help frame the discussion:

The user experience is that a client can use the navDate info to generate an alternative "by date" representation, irrespective of the structures (which are about volumes etc). Guidance is required to ensure that the date a client generates from a potentially UTC navDate value is going to be what was intended, in this case the date you can see on the periodical issue.

[christopher-johnson]

RFC3339 Timezones are treated as offsets from UTC.
Ref: https://www.w3.org/TR/activitystreams-core/#dates

[jpstroop]

@tomcrane Does your example illustrate a problem? Sorry if I'm missing it.

[tomcrane]

@jpstroop the screen shot illustrates the correct behaviour, but there's a fudge.

The value must be an xsd:dateTime literal in UTC, expressed in the form “YYYY-MM-DDThh:mm:ssZ”. If the exact time is not known, then “00:00:00” should be used.

The collection generating the nav has this:

navDate: "1902-01-04T00:00:00.0000000", which is not valid according to the spec. With the UTC Z designator in place, we'd get the problem identified above.

If the navDate is only used for relative positioning in a time-based display, it's fine. But as soon as you want to generate a human-readable version of the navDate (and everyone does), you need to know that the UTC date is for London (or wherever).

[tomcrane]

https://www.w3.org/TR/NOTE-datetime

This profile defines two ways of handling time zone offsets:

1. Times are expressed in UTC (Coordinated Universal Time), with a special UTC designator ("Z").
2. Times are expressed in local time, together with a time zone offset in hours and minutes. A time zone offset of "+hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC. A time zone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC.

A standard referencing this profile should permit one or both of these ways of handling time zone offsets.

[tomcrane]

permit both?

[zimeon]

I don't see any harm in allowing Z and offset forms -- doing so is simpler than profiling the underlying spec to say use only the offset form.

[azaroth42]

To throw a spanner ... if we accept #1246 (navPlace) then we would run into the same problem of how to associate a label with the point or area. Given that we're going to a new major version, we could do something like what @jpstroop suggests that's more verbose but associates the string and data forms together:

"navigationFeatureProperty": [
  {
    "type": "Date",
    "label": "c. 1886",
    "value": "1886-01-01:00:00:00Z"
  },
  {
    "type": "Place",
    "label": "Paris",
    "lat": 35.0
    "long": "5.0
  }
]

[tomcrane]

ah... but with the timezone, I could legitimately generate navigation that presents the date in the client's locale (le 4 janvier) and not have to rely on a label.

navPlace doesn't have an equivalent tz problem, because a latlong (or set of latlongs) is unambiguous.

("Oh, you meant Earth... sorry...")

[azaroth42]

It's unambiguous, but to get from a point to the correct label is impossible -- did you mean Notre Dame, or the Seine, or Paris or France? Not suggesting that this is the right way to go, just brainstorming :)

In isolation, I'm :+1: to allowing either +hh:mm or Z forms

[tomcrane]

more random brainstorming...

Also agree that a very thick line has to be drawn with dates, if you don't want to get into representation nightmares of date precision (which is an argument for having a label). But this feels like the semantics of navDate are shifting... if the object is c. 1886, that belongs to a label/metadata on the object, not on the navDate, which is just for building UI and can't cope with "fl. c 450" etc. ...which argues against my example above. navDate and navPlace must be precise, even if the date they are for is not. But then how does a client know that it is OK to render 4 January 1902 or le 4 janvier 1902 for a newspaper (the most obvious and widely used scenario right now), but not OK to render 1 January 410 for a shipping record related to the Romans leaving Britain? That would need a label... coming round to navWhereAndWhen (sorry, navigationFeatureProperty)

[jpstroop]

But this feels like the semantics of navDate are shifting...

Yeah, I that's how I felt when @tomcrane said

But as soon as you want to generate a human-readable version of the navDate (and everyone does)

above. To me, the use case for navDate was placing on a calendar 🗓 or plotting on some other kind of timeline. Maybe I'm splitting hairs, but one could argue that you're hacking naveDate as soon as you start deriving what is essentially structural metadata from the value. Maybe that's OK but I don't think it's in keeping with the spirit of our intent.

That said, @azaroth42 suggestion above feels like a can of worms too, so I dunno....

[workergnome]

I think the extension mechanism we're defining allows that kind of rich interaction, albeit without 'spec approval'. I'm still somewhat 👎 on navDate and navPlace in general--I understand the utility, but we either need to accept we're doing place and time semantics, or we need to accept that we're doing very, very vague, hand-wavy semantics and any attempt to add rigor to them is going to turn into Owl:Time and WKT, no matter how hard we try to avoid them. There will always be a use case that needs that level of complexity.

[tomcrane]

the use case for navDate was placing on a calendar 🗓

For a usable calendar representation of, say, a newspaper, you need +hh:mm info AND clients should not adjust the date for the user's current time zone. If I click on a calendar representation of The New York Times to look at the 15 November 1960 edition, the user experience should be consistent (same edition) no matter where I am. That is a step up in semantics from a sortable navDate that is just for plotting relative timeline positions, but I think it's the bare minimum to be useful.

[jpstroop]

AND clients should not adjust the date for the user's current time zone.

Do we have any use cases where clients should adjust for the current timezone? To me that stretches the semantics of navDate as the date/time should be about the object itself and when and where it existed regardless of when or where someone is looking at it.

Maybe that's the source of our difference?

[tomcrane]

In a JavaScript client, the navDate property is a string (no dates in JSON - https://weblog.west-wind.com/posts/2014/jan/06/javascript-json-date-parsing-and-real-dates#JSONDatesarenotdates–theyareStrings)

JavaScript Date.parse(...) gives you a long, which you could then format to make a display date. But you need to know where the date is for (which the original string might have given you a clue about, but not necessarily enough of a clue).

You can use a library to parse the date instead.

Perhaps the spec needs to say that if the date is UTC, take care to preserve its UTCness when parsing, so that you produce the correct representation of the date in your UI.

For example: https://stackoverflow.com/questions/17855842/moment-js-utc-gives-wrong-date

[zimeon]

Such JavaScript advice would seem to belong in the implementation notes doc we just talked about in relation to https://github.com/IIIF/api/pull/1305

[azaroth42]

To try and summarize: The intent of navDate is to be able to plot an entry on a calendar or a point on a timeline. That point will typically require a label for the timestamp, as well as for the object that is related to the timestamp. The timestamp label could be provided by the manifest (with potential for internationalization) or it could be generated by the viewer. Currently it must be generated by the viewer, and the viewer cannot generate the right label due to the required UTC timezone.

I agree with David that there will always be use cases that need more and more semantics and precision, and that we should NOT do that in the Presentation API. The presentation of the information does require a label for the human, however. I agree with Jon (if I read his comment correctly) that the date is about the object, and hence should always be localized to the object, not to the user.

I think that the minimum fix for that is to allow offset timezones along with Z. Whether or not the manifest data can also provide a label could be discussed separately.

[tomcrane]

I agree with @azaroth42's summary. I also think that newspaper/periodical browsing use cases will very quickly reach the limits of navDate and that a community practice external to the Presentation API will follow rapidly (ccing @kestlund and @glenrobson again).

[workergnome]

Is there any reason not to move navDate/navPlace out to an extension immediately? I agree that they're useful, but I also think that they're somewhat out of place in the spec as it stands, since they're explicitly designed to present computationally-mediated semantic metadata about the content of a manifest for specific interface interactions, which we don't do anywhere else in the spec.

[glenrobson]

Just to share some experience with implementing https://journals.library.wales/ which uses navDate for all Journal issues:

https://journals.library.wales/view/2520560/2520583/0#?xywh=-669%2C-196%2C4020%2C3913

and also as a facet in the search interface:

https://journals.library.wales/search?query=jones

Having the current wording which encourages a best effort specific date, made deciding on dates a lot easier and more useful for users. For the majority of the content we new the year and month of publication but not the day so defaulted to the 1st at 00:00:00. There were a few titles which we didn't know a month and defaulted to the 1st of January. There wasn't a single issue where we knew the time of publication and I can't think of many historical collections where the time contingent of the date would be known. At most there are some Newspaper issues which have a morning and evening addition but I suspect the exact time would be a guesstimate. Currently in the NLW Newspapers these are distinguished by label rather than having different times.

In the UV example above it is possible to see a 'label' for the navDate by looking at the collection members property:

{
      "@id": "http://dams.llgc.org.uk/iiif/2.0/2520583/manifest.json",
      "@type": "sc:Manifest",
      "navDate": "1891-09-01T00:00:00Z",
      "license": "http://rightsstatements.org/vocab/UND/1.0/",
      "label": "Vol. I - No. 3 - Michaelmas term 1891"
    },

or in the manifest label which matches the label above i.e. Vol. I - No. 3 - Michaelmas term 1891.

I'm not sure I understand the issue with UTC but may not be seeing it with British dates and times. For the Journal case above where we don't know the time, only showing the date portion as the UV currently does was what we wanted. We wouldn't want a client to adjust the date to match the users timezone. I notice in the date browsing interface in the UV if you switch the language to Welsh then the dates are still in English. I suspect the NLW would prefer that also to be in Welsh but I think thats a client translation issue rather than something that should go into the manifest.

Thinking of the newspaper morning and evening addition, I think we would expect the client to show the time in the manifest not adjusted to the local users timezone.

[mikeapp]

Community call 12/20: require a timezone/Z and assume UTC if no offset or Z timezone indication, clients should treat as UTC.

[zimeon]

Fixed by #1381