You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficcontrol.apache.org by GitBox <gi...@apache.org> on 2021/06/05 00:10:42 UTC

[GitHub] [trafficcontrol] zrhoffman commented on a change in pull request #5886: Fix Docs spacing/indentation and RFC3339 time

zrhoffman commented on a change in pull request #5886:
URL: https://github.com/apache/trafficcontrol/pull/5886#discussion_r645910404



##########
File path: docs/source/glossary.rst
##########
@@ -44,7 +44,7 @@ Glossary
 	Cache Groups
 		A group of caching HTTP proxy servers that together create a combined larger cache using consistent hashing. Traffic Router treats all servers in a :dfn:`Cache Group` as though they are in the  same geographic location, though they are in fact only in the same general area. A :dfn:`Cache Group` has one single set of geographical coordinates even if the :term:`cache servers` that make up the :dfn:`Cache Group` are actually in :term:`Physical Locations`. The :term:`cache servers` in a :dfn:`Cache Group` are not aware of the other :term:`cache servers` in the group - there is no clustering software or communications between :term:`cache servers` in a :dfn:`Cache Group`.
 
-  		There are two basic types of :dfn:`Cache Groups`: EDGE_LOC and MID_LOC ("LOC" being short for "location" - a holdover from when :dfn:`Cache Groups` were called "Cache Locations). Traffic Control is a two-tiered system, where the clients get directed to the Edge-tier (EDGE_LOC) :dfn:`Cache Group`. On cache miss, the :term:`cache server` in the Edge-tier :dfn:`Cache Group` obtains content from a Mid-tier (MID_LOC) :dfn:`Cache Group`, rather than the origin, which is shared with multiple Edge-tier :dfn:`Cache Groups`. Edge-tier :dfn:`Cache Groups` are usually configured to have a single "parent" :dfn:`Cache Group`, but in general Mid-tier :dfn:`Cache Groups` have many "children".
+		There are two basic types of :dfn:`Cache Groups`: EDGE_LOC and MID_LOC ("LOC" being short for "location" - a holdover from when :dfn:`Cache Groups` were called "Cache Locations). Traffic Control is a two-tiered system, where the clients get directed to the Edge-tier (EDGE_LOC) :dfn:`Cache Group`. On cache miss, the :term:`cache server` in the Edge-tier :dfn:`Cache Group` obtains content from a Mid-tier (MID_LOC) :dfn:`Cache Group`, rather than the origin, which is shared with multiple Edge-tier :dfn:`Cache Groups`. Edge-tier :dfn:`Cache Groups` are usually configured to have a single "parent" :dfn:`Cache Group`, but in general Mid-tier :dfn:`Cache Groups` have many "children".

Review comment:
       > Traffic Control is a two-tiered system
   
   With the introduction of Flexible Topologies, Traffic Control is no longer a strictly two-tiered system, but, since this PR relates to whitespace and the TO date format, rewording this should go in a separate PR.

##########
File path: docs/source/api/index.rst
##########
@@ -124,6 +124,14 @@ The following, reserved properties of ``summary`` are guaranteed to always have
 ``count``
 	``count`` contains an unsigned integer that defines the total number of results that could possibly be returned given the non-pagination query parameters supplied by the client.
 
+.. _non-rfc-datetime:
+
+Traffic Ops's Custom Date/Time Format
+-------------------------------------
+Traffic Ops will often return responses from its API that include dates. As of the time of this writing, the vast majority of those dates are written in a non-:rfc:3339 format (this is tracked by :issue:`5911`). This is most commonly the case in the ``last_updated`` properties of objects returned as JSON-encoded documents. The format used is :samp:`{YYYY}-{MM}-{DD} {hh}:{mm}:{ss}±{ZZ}`, where ``YYYY`` is the 4-digit year, ``MM`` is the two-digit (zero padded) month, ``DD`` is the two-digit (zero padded) day of the month, ``hh`` is the two-digit (zero padded) hour of the day, ``mm`` is the two-digit (zero padded) minute of the hour, ``ss`` is the two-digit (zero padded) second of the minute, and ``ZZ`` is the two-digit (zero padded) timezone offset in hours of the date/time's local timezone from UTC (the offset can be positive or negative as indicated by a ``+`` or a ``-`` directly before it, where the sample has a ``±``).

Review comment:
       Should this definition include an example?




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org