-
-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gigasecond: use times (not dates) for inputs and outputs #39
Comments
👍 for no DST; in fact, it would make the most sense to default everything to UTC. One thing that I was wondering about exercism 'opinion' on - 3rd party libs. I see it as more of a challenge to disallow/discourage them, but what you're describing is much simpler (in 'pure' Clojure) with the clj-time lib than relying on |
In terms of Date I'm not really sure what to choose. Mostly I think we've just gone with standard/core functionality around generic date/time, whereas for things like prime numbers, leap years, and a couple of other things, we discourage (or disable) existing behavior. |
Nobody wants to use the existing behaviour for leap years... have you used |
No, actually :) I haven't! |
Lucky :) |
It's not so bad haha. |
Also 1.7 is deprecated by Oracle. I can track down a link of proof if needed. Maybe we should require users to use 1.8. Thoughts? |
If we required 1.8, we could use LocalDateTime here, which would be nice. Here is the oracle doc on java support http://www.oracle.com/technetwork/java/eol-135779.html (Java 7 support ended in April 2015). |
My opinion with this is that asking for a date leaves some doubt as to when to start counting seconds... do you start at the beginning of the day or the end of the day? If I ask for a birthday you will not likely give me down to the seconds. The wording of "moment" leaves this exercise a bit open, the discussion about what to ask for in the argument list, the fact there is ambiguity when asking for a date, rather than a time, the fact that at least in the Ruby track, the most common solutions allows to even just provide Leaving it open provides for a number of solutions and room to discuss a lot of things for the exercise. Not asking for time or date allows for this. Of course, you also have the potential for time zone complications. :) |
A duration of a gigasecond should be measured in seconds, not
days.
The
gigasecond
problem has been implemented in a number of languages,and this issue has been generated for each of these language tracks.
This may already be fixed in this track, if so, please make a note of it
and close the issue.
There has been some discussion about whether or not gigaseconds should
take daylight savings time into account, and the conclusion was "no", since
not all locations observe daylight savings time.
The text was updated successfully, but these errors were encountered: