<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 23, 2016 at 3:21 AM, Paul Harrison <span dir="ltr"><<a href="mailto:paul.harrison@manchester.ac.uk" target="_blank">paul.harrison@manchester.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 2016-03 -23, at 08:52, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br></span></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
> So, excuse me for bringing this up so late, but I think this is<br>
> serious enough to even make me propose an erratum if we can't fix the<br>
> text any more.<br>
><br>
> This being machine readable data, I'd argue strongly we should<br>
> require, in effect, UTC (more exactly, timestamps without timezone,<br>
> since I'm not really concerned if someone uses TAI or TDB if they<br>
> like; there just shouldn't be time zones).<br></span></blockquote><div><br></div><div>I have to agree that allowing time zones in the UWS 1.0 document was a mistake. My opinion is that the 1.1 specification should correct this by stating that timestamps are always UTC and that an errata should indeed be added to the 1.0 spec.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><br>
> True, that is a change that might theoretically invalidate existing<br>
> services, but really: Does anyone put in anything else but UTC into<br>
> the time fields?<br>
<br>
<br>
</span>I am happy with UTC - I live in the UK and work at an observatory - it is very natural for me as our computer clocks always tell UTC, but it might not be for others.<br>
<br>
What have people actually been doing in their implementations? I suspect that as most of the implementations have been connected to TAP services (which are probably DALI compliant) so that people have probably been using timestamps without timezone designators, and hopefully UTC. I imagine that it would not be a big disruption to change any existing non DALI timestamp compliant services. In java for instance it would be just a case of explicitly setting the timezone to UTC and then having a custom date formatter that did not emit the timezone specifier.<br></blockquote><div><br></div><div>The CADC uses UTC in all UWS timestamps.</div><div><br></div><div>Introducing an errata to 1.0 could be a headache for some implementations. Reiterating what Paul asks above: does anyone use something other than UTC?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As for how much of a change to the formal standard this would be, it seems that as we have not reached the REC stage then this update to be DALI compliant can still be made.<br></blockquote><div><br></div><div>Yes, I agree.</div><div><br></div><div>Brian</div></div></div></div>