Skip to content
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

Closed
kytrinyx opened this issue Jan 24, 2015 · 9 comments
Closed

gigasecond: use times (not dates) for inputs and outputs #39

kytrinyx opened this issue Jan 24, 2015 · 9 comments

Comments

@kytrinyx
Copy link
Member

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.

@canweriotnow
Copy link
Contributor

👍 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 java.util.Date and Java interop. But I'll put investigating this on my TODO list, DateTime code is my area of dubious expertise 😒

@kytrinyx
Copy link
Member Author

kytrinyx commented Apr 9, 2015

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.

@canweriotnow
Copy link
Contributor

Nobody wants to use the existing behaviour for leap years... have you used java.util.GregorianCalendar? 😨

@kytrinyx
Copy link
Member Author

No, actually :) I haven't!

@canweriotnow
Copy link
Contributor

Lucky :)

@yurrriq
Copy link
Member

yurrriq commented Aug 19, 2015

It's not so bad haha. doto to the rescue. Also date/time handling is greatly improved in the JDK 1.8.

@yurrriq
Copy link
Member

yurrriq commented Aug 19, 2015

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?

@haus
Copy link
Contributor

haus commented Nov 6, 2016

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).

@kotp
Copy link
Member

kotp commented Nov 6, 2016

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 12.76 as a number of seconds and a "gigasecond" is not-surprisingly added to that number of seconds, in the most generic of sense.

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. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants