Richard,
You (and my student Dimitris who responded directly to me at the
same time) are correct – it’s the OS.
And thanks for the pointer about HH versus hh – I wasn’t aware of that subtlety.
- Steve
Steven R. Ray, Ph.D.
Distinguished Research Fellow
Carnegie Mellon University
NASA Research Park
Building 23 (MS 23-11)
P.O. Box 1
Moffett Field, CA 94305-0001
Email: [email protected]
Phone: (650) 587-3780
Cell: (202) 316-6481
Skype: steverayconsulting
cid:[email protected]
From: [email protected] [mailto:[email protected]]
On Behalf Of Richard Cyganiak
Sent: Thursday, May 03, 2018 9:59 AM
To: [email protected]
Subject: Re: [topbraid-users] Surprising behavior of spif:parseDate
Hi Steve,
1. spif:parseDate turns a date-as-string into a date-as-xsd:dateTime. But
you’re already passing in an xsd:dateTime, so all the function does is turn the
xsd:dateTime into a string, and then turn it back to an xsd:dateTime according
to your pattern. This may not be what you want?
2. The pattern is a bit dodgy. You probably want HH:mm:ss instead of hh:mm:ss.
The former is for parsing 24h notation, the latter for parsing 12h notation,
so, 12:00:00 and 00:00:00 will be treated as the same time (midnight).
3. The pattern doesn’t include a time zone. So, spif:parseDate will ignore any
time zone modifier that may be present on the input string. The input
2018-03-11T02:00:00Z will be parsed just like the input 2018-03-11T02:00:00,
which, for lack of a time zone specifier, is *probably* (don’t quote me on
this) interpreted as a local time according to your OS settings.
If the input has a time zone, you probably want to append an X to the end of
the pattern to instruct spif:parseDate to consider the time zone.
4. I can’t see any strange jump when running this query, so I don’t know what
exactly you are seeing. This is *probably* because my OS is set to a different
time zone from yours.
5. So my best guess is that the hidden USA-centric behaviour might be not in
spif:parseDate but in your OS settings?!?
Time zones are complicated, and I in no way am confident that all of the above
is correct.
Richard
On 3 May 2018, at 16:33, Steve Ray (CMU) <[email protected]> wrote:
Do I detect some hidden USA-centric behavior in the spif:parseDate function?
The value for ?time in the snippet below just happens to be the transition time
for Daylight Savings Time in the USA, but certainly not for UTC. Why the
strange jump of one hour for just this one hour? The next hour is back to
normal operation.
SELECT *
WHERE {
BIND (xsd:dateTime("2018-03-11T02:00:00Z") AS ?time) .
BIND (spif:parseDate(?time, "yyyy-MM-dd'T'hh:mm:ss") AS ?result) .
}
- Steve
Steven R. Ray, Ph.D.
Distinguished Research Fellow
Carnegie Mellon University
NASA Research Park
Building 23 (MS 23-11)
P.O. Box 1
Moffett Field, CA 94305-0001
Email: <mailto:[email protected]> [email protected]
Phone: (650) 587-3780
Cell: (202) 316-6481
Skype: steverayconsulting
<image001.png>
--
You received this message because you are subscribed to the Google Groups
"TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to <mailto:[email protected]>
[email protected].
For more options, visit <https://groups.google.com/d/optout>
https://groups.google.com/d/optout.
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
Virus-free.
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
www.avg.com
--
You received this message because you are subscribed to the Google Groups
"TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
