Re: Please review

On 16/05/2016 18:52, Phillips, Addison wrote:
> This has been a long standing action item for me that I'd like to complete. Could you please review this link and send comments to the list:

hi Addison, here are some comments.  The value of some of these may, i 
suppose, depend on who your target audience is - not yet described at 
the top.  Unfortunately, despite frequent exposure to this topic, it's 
sufficiently complicated and my memory is sufficiently threadbare these 
days, that i have to keep relearning it, so most probably apply for me 
though may not apply to the intended reader.

[1] i'm not sure the opening gambit of the explanatory text is very 
helpful without some additional positioning of the user or pointers to 
info about types of time, ie. the quote just after "The Working with 
Timezones WG Note says:" could lead to questions such as

what's an 'observed time value'? what's 'incremental time'? That's just 
the first sentence ;-)

*how* are they to be combined with local information? what is an 
'acceptable' range of incremental time values?

[2] typo: epoch data

[3] "Depending on the time zone used to create and display an 
incremental time value, the same floating date value could be as much as 
two days off. "

that sounds odd, because you just said that time zones are not used for 
floating times, but now you say 'depending on the time zone used...'

[4] good that you are explaining what incremental time is, although i 
might have preferred an upfront para saying something like, "the types 
of time values you can have include observed time, floating time, 
incremental time, local time..." (gives you a feeling you've seen the 
overall picture)

[5] i think it would be helpful to clarify exactly what you mean when 
you say 'time zone' before referring to it, since i'm sure lots of 
people reading this will assume it's just +8 etc.

[6] the question draws a division between what is a floating time and 
how to handle them that's not clearly reflected in the body.  The quick 
answer addresses only the first, and the details sort of expand on that, 
but merge with handling information.  Maybe have an introductory section 
for definitions/explanations under Details, and beef up the quick answer 
with a summary of the handling stuff?

perhaps it's actually over-ambitious to both define floating time and 
talk about implementation issues in the same article?  Perhaps we should 
have a definitions article, like 
(Character encodings: Essential concepts), which can be pointed to (with 
class="termref" links) for definitions?  Or link to the appropriate part 
of the timezone note?  Then have an introductory para that says, we 
assume you're familiar with these concepts.

[7] You also seem to address two specific issues. I'd prefer to see 
separate, signposted subsections for each, clearly summarising the 
problem statement of each at the start of the section.

[8] "Depending on the time zone used to create and display an 
incremental time value"
maybe better something like
"Depending on the time zone used to create and display a time that is 
derived from an incremental time value"

[9] "this can lead to issues" seems a little handwavy. Maybe clarify 
what issue this leads to?

[10] "the element date_target contain a string representing that date"
typo, missing 'to'
actually maybe better s/contain/display/

[11] "If you journal " does this mean 'if you log'? or is there some 
additional technical meaning hidden behind 'journal'?

hope that helps,

Received on Wednesday, 25 May 2016 15:07:21 UTC