Re: Details of dateTime operations

On 03/12/10 15:25, Steve Harris wrote:
> On 2010-12-03, at 14:54, Andy Seaborne wrote:
>> On 03/12/10 14:41, Steve Harris wrote:
>>> On 2010-12-03, at 14:12, Andy Seaborne wrote:
>>>
>>>> Easier (hopefully!)
>>>>
>>>> YEAR, MONTH, DAY, HOURS, MINUTES
>>>>   Return an xsd:integer.
>>>> SECONDS
>>>>   Return an xsd:decimal (fractional seconds possible).
>>>
>>> Sounds good.
>>>
>>> What about a NOW()? Returning an xsd:dateTime for the current time, in the Z timezone. e.g.
>>
>> I'm happy with that and I agree it's very useful.  It wasn't in the list we decided on so I haven't included it. It should return the same dateTime throughout the query execution.  c.f. fn:current-dateTime ("This function is ·stable·")
>
> I'd be happy with CURRENT_DATETIME() too.
>
> Stability is probably good.
>
>> ARQ already has afn:now() - TZ is locale but of course you can run your locale in Z.
>
> Many systems have one of each, c.f. time() and gmtime().

It's the value that matters - it's just the presentation that needs a TZ.

> Strangely F&O doesn't specify the timezone used in fn:current-dateTime, the example is in zulu time, but it doesn't say that's the desired behaviour.

"""Returns the current dateTime (with timezone) from the dynamic context."""

Every XQuery/XPath execution has a dynamic context that includes the 
default timezone from outside.

SPARQL does not have this, which makes sense because data may come from 
one place and be queried in another, so no natural, safe default, while 
the XML case is more likely to be a collection of documents on the server.

>> In the useful camp might be VERSION()->string (unless security concerns?)
>
> Plain literal?

Simple literal!

	Andy

Received on Friday, 3 December 2010 15:33:15 UTC