[UICIRC-178] SPIKE - Tenant-selected timezone compliance for backend modules Created: 08/Jan/19 Updated: 19/Sep/19 Resolved: 15/Feb/19 |
|
| Status: | Closed |
| Project: | ui-circulation |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Story | Priority: | P2 |
| Reporter: | sthomas (Inactive) | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||
| Sprint: | EPAM-Veg Sprint 7, EPAM-Veg Sprint 8, EPAM-Veg Sprint 9 | ||||||||||||||||||||||||||||||||||||
| Story Points: | 8 | ||||||||||||||||||||||||||||||||||||
| Development Team: | Vega | ||||||||||||||||||||||||||||||||||||
| Description |
|
All due date calculations need to respect the timezone chosen for the tenant. While
The SPIKE should be used to define general technical solution, how to make timezone setting effective throughout the system. Investigation of scope of work across affected modules is out of scope of this particular SPIKE. Original observations:
Deliverables:
Questions:
|
| Comments |
| Comment by sthomas (Inactive) [ 08/Jan/19 ] |
|
Marc Johnson and Kostyantyn Khodarev - I currently have this spike set to Draft because I want to make sure that I'm accurately describing the issue and scoping this effort correctly. Can you let me know if there are any changes that need to be made? I also haven't set Vega to the assigned team as it wasn't clear during our discussion whether other teams should be a part of this effort. Can you let me know your thoughts? Thanks. |
| Comment by sthomas (Inactive) [ 08/Jan/19 ] |
|
Marc Johnson and Kostyantyn Khodarev - Once we've established scope and investigator(s), we'll want to get an estimate in place for the level of effort required to perform the Spike and get that into our capacity planning. Thanks. |
| Comment by Marc Johnson [ 10/Jan/19 ] |
|
sthomas Kostyantyn Khodarev Jakub Skoczen Zak Burke Here is a summary of my understanding. Thoughts welcome. Situation
Desired Outcome
Assumptions
Spike Scope
Highlights of due date calculation (based upon current work in
Decisions
Questions
|
| Comment by Khalilah Gambrell [ 10/Jan/19 ] |
|
sthomas, Kostyantyn Khodarev, Marc Johnson, Vega will conduct sprint planning tomorrow. Do we want to consider this spike or some aspect of this spike in the next sprint? If so, can we confirm today? |
| Comment by Kostyantyn Khodarev [ 14/Jan/19 ] |
|
sthomas Marc Johnson Jakub Skoczen Does FOLIO support Daylight Saving Time? |
| Comment by Cate Boerema (Inactive) [ 15/Jan/19 ] |
|
sthomas, Khalilah Gambrell, Marc Johnson it would be good to make some progress on this investigation and it looks like we want input from Core and Vega. Can we put a spike for each team into Sprint 55 to ensure it gets some attention? |
| Comment by Khalilah Gambrell [ 15/Jan/19 ] |
|
Cate Boerema, Kostyantyn Khodarev will revise this spike so we can pull into Sprint 55. Once he completes revision, I believe the plan is to create additional spikes for Core and Vega. |
| Comment by Marc Johnson [ 16/Jan/19 ] |
|
Kostyantyn Khodarev Here are my thoughts on your questions.
I believe FOLIO uses the tz form of timezone which I believe means that daylight saving transitions are included in the definition. This is probably worth investigating as part of the spike.
I believe this overlaps with the decision:
My personal preference is that the system should fail if not timezone has been chosen (though this also means that the system will fail if we choose to store this information in the configuration API and this is transitively unavailable).
I don't think it makes a difference which timezone calculations are performed in, as long as the date and times that are created by the system reflect the chosen timezone (e.g. end of day in ET, can be converted to UTC if desired, but the original decision needs to be ET). It might be that I have a different understanding of calculations, what do you mean by calculations? By calculations I refer to moving a date and time by an period of time, working out the difference or comparison. But not the decision of what a fragment (e.g. 08:00) should mean when turned into a date and time. Does that make sense?
It has been previously agreed that all date and time representations in requests or responses to API endpoints, and in storage, are intended to be UTC. I think we could review that decision. By convert back to local date-time as late as possible, I interpret that as typically only done in presentation, e.g. UI. Is that a sensible interpretation? |
| Comment by Marc Johnson [ 18/Jan/19 ] |
|
Kostyantyn Khodarev Khalilah Gambrell Given this has been pulled into the current sprint, is it possible to expand upon what
means in terms of scope for this work? |
| Comment by Kostyantyn Khodarev [ 18/Jan/19 ] |
|
Marc Johnson Technical solution here means a document with a description of how to work with date-time (how to store, what java library to use, request-response parameters format etc.), some general, module ignorant approach
Could you provide a link to a doc or story where it was agreed that all date and time representations in requests or responses to API endpoints are intended to be UTC? The only document i found is about storing date and time in UTC. |
| Comment by Marc Johnson [ 18/Jan/19 ] |
|
Kostyantyn Khodarev Ok, thank you. From your response, my understanding is that this work will provide all of the decisions I outlined in my post above, and likely more.
I'm basing this on a comment Zak Burke made on
There might be other documentation in JIRA issues, a cursory search didn't find the specific decision, [DMOD-256] and
|
| Comment by Kostyantyn Khodarev [ 18/Jan/19 ] |
|
Marc Johnson ok, thanks. Probably it's good to have a single format for all date-time parameters that includes time zone information. About DST support. Due to the fact FOLIO uses region-based IDs DST support is out of the box (https://docs.oracle.com/javase/8/docs/api/java/time/ZoneId.html, Time-zone IDs section) |
| Comment by Marc Johnson [ 22/Jan/19 ] |
|
Given that this has been re-scoped to general guidance for all modules, I have renamed the issue.
Given that these decisions are owned by the core platform team, I think the review needs to include a broader audience, including Jakub Skoczen and other folks. |
| Comment by Jakub Skoczen [ 31/Jan/19 ] |
|
Kostyantyn Khodarev Marc Johnson IMHO, there are two main areas here:
|
| Comment by Jakub Skoczen [ 04/Feb/19 ] |
|
David Crossley Kostyantyn Khodarev we discussed that it makes sense to put up a short documentation on the dev website about working with dates and date calculations in FOLIO. Kostya will prepare the write-up, can you help him finding the right place to put it up? |
| Comment by David Crossley [ 04/Feb/19 ] |
|
Please provide the content text and i will expand it into an actual document. See
|
| Comment by Kostyantyn Khodarev [ 04/Feb/19 ] |
|
David Crossley updated attached document |
| Comment by Kostyantyn Khodarev [ 05/Feb/19 ] |
|
Example of API endpoint with date-only query parameters:
Should this be converted to format: datetime (RFC3339) ? |
| Comment by Jakub Skoczen [ 08/Feb/19 ] |
|
Kostyantyn Khodarev Marc Johnson Marc might have a different opinion but I don't think it should – if you do, changing the tenant timezone will not have any impact on them (as we have discussed above) so you would suddenly see "days" starting/ending in the middle of the day. |
| Comment by Marc Johnson [ 09/Feb/19 ] |
|
Kostyantyn Khodarev I think there are likely cases where a date is a more appropriate construct, rather than a datetime. My interpretation of RFC 3339 is that it defines the full-date representation for this purpose, and that RAML 1.0 defines the date-only type for this purpose. Hence, I think each of the examples need considering in context, and we should use the most semantically appropriate type to convey the meaning and expectations to clients. What does the endpoint GET /calendar/periods?startDate=X do? When a client asks the following question, what should it expect as the answer? GET /calendar/periods?startDate=2019-02-15 |
| Comment by Kostyantyn Khodarev [ 11/Feb/19 ] |
|
Marc Johnson
{
"openingPeriods": [
{
"openingDay": {
"openingHour": [
{
"startTime": "08:00",
"endTime": "17:00"
}
],
"allDay": false,
"open": true,
"exceptional": false
},
"date": "2019-02-15T00:00:00.000+0000"
},
{
"openingDay": {
"openingHour": [
{
"startTime": "00:00",
"endTime": "23:59"
}
],
"allDay": true,
"open": false,
"exceptional": false
},
"date": "2019-02-16T00:00:00.000+0000"
},
{
"openingDay": {
"openingHour": [
{
"startTime": "00:00",
"endTime": "23:59"
}
],
"allDay": true,
"open": false,
"exceptional": false
},
"date": "2019-02-17T00:00:00.000+0000"
},
{
"openingDay": {
"openingHour": [
{
"startTime": "08:00",
"endTime": "17:00"
}
],
"allDay": false,
"open": true,
"exceptional": false
},
"date": "2019-02-18T00:00:00.000+0000"
},
{
"openingDay": {
"openingHour": [
{
"startTime": "00:00",
"endTime": "23:59"
}
],
"allDay": true,
"open": false,
"exceptional": false
},
"date": "2019-02-19T00:00:00.000+0000"
},
{
"openingDay": {
"openingHour": [
{
"startTime": "00:00",
"endTime": "23:59"
}
],
"allDay": true,
"open": false,
"exceptional": false
},
"date": "2019-02-20T00:00:00.000+0000"
},
{
"openingDay": {
"openingHour": [
{
"startTime": "08:00",
"endTime": "17:00"
}
],
"allDay": false,
"open": true,
"exceptional": false
},
"date": "2019-02-21T00:00:00.000+0000"
},
{
"openingDay": {
"openingHour": [
{
"startTime": "08:00",
"endTime": "17:00"
}
],
"allDay": false,
"open": true,
"exceptional": false
},
"date": "2019-02-22T00:00:00.000+0000"
},
{
"openingDay": {
"openingHour": [
{
"startTime": "00:00",
"endTime": "23:59"
}
],
"allDay": true,
"open": false,
"exceptional": false
},
"date": "2019-02-23T00:00:00.000+0000"
},
{
"openingDay": {
"openingHour": [
{
"startTime": "00:00",
"endTime": "23:59"
}
],
"allDay": true,
"open": false,
"exceptional": false
},
"date": "2019-02-24T00:00:00.000+0000"
}
],
"totalRecords": 75
}
|
| Comment by Kostyantyn Khodarev [ 11/Feb/19 ] |
|
Marc Johnson Jakub Skoczen you are right, in some cases date-only option is more appropriate than full date So, you propose to use formats like date-only for request parameters where time is not needed, correct? |
| Comment by sthomas (Inactive) [ 15/Feb/19 ] |
|
It's my understanding from a discussion with Kostyantyn Khodarev that there is general agreement to the approach that's described here. EPAM-Vega is moving forward with development related to mod-cal. |
| Comment by Jakub Skoczen [ 28/Feb/19 ] |
|
Kostyantyn Khodarev should the attached timezone.txt document be updated with information about full-date and date-only query parameters before David puts the contents on dev.folio.org? |
| Comment by Kostyantyn Khodarev [ 28/Feb/19 ] |
|
Jakub Skoczen Yes, i'll update document with information about date-only query parameter |
| Comment by David Crossley [ 06/Mar/19 ] |
|
The document is now added. See
|