Re: Negative values should be returned from seconds-from-dateTime()

Hi Mark,

I don't think the spec says that the sign of the difference should be 
removed.

A difference can be positive or negative.

The wording appears to take for granted that it is reasonably obvious to 
implementers that they should take the difference in a way that makes 
sense, i.e. that Jan. 1, 1970 midnight zulu time should be taken as the 
"origin" of the oriented time line, so that times *after* that will come 
out positive and times earlier will come out negative.  The difference 
suggested by the spec is (parameter - origin), converted to seconds.

The second example in the spec shows a postivie value because 
'1970-01-01T00:00:00-08:00' is actually 8 hours *later* than midnight zulu 
time.

Cheers,
John M. Boyer, Ph.D.
Senior Technical Staff Member
Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:
"Mark Birbeck" <mark.birbeck@webbackplane.com>
To:
public-forms <public-forms@w3.org>
Date:
08/01/2008 06:02 AM
Subject:
Negative values should be returned from seconds-from-dateTime()




Hello all,

I've been having a lot of fun :( trying to get the various date/time
functions working in the Ubiquity XForms library, and most of the
problems arise from timezone switching.

Anyway, one of the tests for seconds-from-dateTime() involves a
timezone, as follows:

  Assert.areEqual(28800,
evalXPath('seconds-from-dateTime("1970-01-01T00:00:00-08:00")').numberValue());

This test is based on an example in section 7.9.6 of the XForms 1.1 spec.

My question is, why is the example saying that it should be a positive
number? It's true that the spec says:

  "...the return value is equal to the number of seconds difference..."

which would imply making the number positive -- so the result is
correct according to the spec. But I wonder what we gain by *losing*
the sign of the result.

The problem is further compounded when you use this function with the
complementary seconds-to-dateTime(). Nothing says that
seconds-to-dateTime() should _not_ take a negative value, so the
problem we have is that the following pair of calls does not give you
back what you started with:

  seconds-from-dateTime(seconds-to-dateTime(-28800))

I.e, the result according to the spec is 28800, when it could easily be 
-28800.

I think that the fix is to simply change the example in the spec,
which would send a clear signal to implementers:

  Example:

  seconds-from-dateTime('1970-01-01T00:00:00Z')
  returns 0

  seconds-from-dateTime('1970-01-01T00:00:00-08:00')
  returns -28800

Note that the Ubiquity XForms unit tests for this are currently
passing because I've set the functions to return a negative number.
Obviously I'll change that if need be, but I'll see what points come
up on this discussion first.

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)