gigasecond: use times (not dates) for inputs and outputs about common-lisp HOT 8 CLOSED

All good.

For the record:

• checked example.lisp
  • it uses 'encode-universal-time` to convert user input to seconds (per http://www.lispworks.com/documentation/lw50/CLHS/Body/f_encode.htm)
  • it adds a billion
• ran tests on example code: passed

from common-lisp.

Thanks!

from common-lisp.

I looked at this, and the example does use times, but the test suite uses dates, not times: https://github.com/exercism/xlisp/blob/master/gigasecond/gigasecond-test.lisp

from common-lisp.

Maybe I don't understand. Should the test suite require year month day hour minute second? (I thought perhaps some tests were doing an inappropriate conversion).

We've discussed the "precision problem" briefly here:

http://exercism.io/submissions/d9d364a3e67e4f2ea6d245fc6116a59f

And I took a shot at implementing something that seemed naively reasonable for the problem as I understand it here (ugly hack iteration):

http://exercism.io/submissions/1086718414394ce89a22fe8983755cca

from common-lisp.

Should the test suite require year month day hour minute second?

Yeah, that's what I was thinking. A gigasecond from 10pm at night will give a different date than a gigasecond from 3am.

I think that the "anniversary/birthday" is probably derailing from the underlying problem a bit. People don't generally know or care what time of day they were born.

from common-lisp.

I'm fine with @wobh modification to this exercise (doesn't really change it much in my opinion). But there was a mention about about DST. I think explicitly stating to not take DST into consideration will make the problem weirder. Here in the Common Lisp version using the built in tools to convert to and from a 'universal time' (analogous to Unix time_t) takes DST into consideration (when that data is available to the Lisp implementation). To not do that would mean not using the built in functions* and try to roll ones-own date/time functionality which, as we all know, is infamously difficult.

• Or maybe I'm missing something about how to use these funcions.

from common-lisp.

@verdammelt I wondered about that too, but I think we'll be okay on that front:

CL-USER> (values
          (multiple-value-list (decode-universal-time 0))
          (multiple-value-list (decode-universal-time 0 0))
          (multiple-value-list (decode-universal-time (expt 10 9)))
          (multiple-value-list (decode-universal-time (expt 10 9) 0)))
(0 0 16 31 12 1899 6 NIL 8)
(0 0 0 1 1 1900 0 NIL 0)
(40 46 17 9 9 1931 2 NIL 8)
(40 46 1 10 9 1931 3 NIL 0)

So the tests I wrote assume timezone zero, GMT. If there were something in the README about this, it would help, but even if not, the user's tests will consistently fail by their timezone offset. This should be a big enough clue, for most users to realize what the problem is, but I added epoch tests to make it more obvious. They might look at their options for decode-universal-time or they might ask about it in a chat or submission, or they hack up a custom offset for their own timezone or file a bug or something.

I considered adding a local time-zone offset function to apply to the tests and expected values so that they would just convert to user's the local time behind the scenes, but it looks just like example code (only with tz*3600 instead of 10^9), and thus, kind of a spoiler for anyone reading the tests.

from common-lisp.

Hmm, I am deeply suspicious about doing things with time, doubly so when it comes to timezones and quadruply so when we add DST to the mix.

But, it sounds like we might be ok. The user will get errors that are off by a delta = their TZ (+/- DST offset for the date in question).

I'd say merge in your pull request and close this ticket.

from common-lisp.