Skip to content

Feature added: default values #14

Closed
wants to merge 1 commit into from

4 participants

@hannesg
hannesg commented Nov 13, 2010

Hi there's
I added a 'defaults' param to all Date/Time parsing methods. This is usefull, if you want to allow partial dates to be valid, but not use today or 0 as default value for missing fragments.
Example:
You have "%d.%m.%Y" as valid time format. Before this commit "12.4.2009" would be parsed to "Sun, 12 Apr 2009 00:00:00". After this commit you could for example provide a default time. The following code
Time.zone.parse("12.4.2009",{:hour=>18,:min=>30})
would be then evaluated to "Sun, 12 Apr 2009 18:30:00".

Do you have any questions?

Greetings
HannesG

@clemens
Owner
clemens commented Nov 18, 2010

Hi,
I'll review that over the next couple of days and get back to you. In any case, thanks for caring. :-)

@SKoschnicke

Any chance that this will be integrated soon? Would be really helpful.

@clemens
Owner
clemens commented Apr 28, 2011

I've been thinking about this and I don't think that this should be in the gem. If the user is asked to provide a date and time, entering only the date is technically an invalid entry. IMO, invalid entries should be handled by the application rather than the gem – the application could either show/raise some kind of error or gracefully handle the situation (as proposed in this patch). I actually think that the current behavior is also wrong or at least not ideal. Should I remove the code that defaults to the current time's fields?

@SKoschnicke

Yes, the current behavoir is not ideal. The application has no chance to know if the user entered a time of 0:00:00 or if the gem added this. But the goal is to have entered data dependent on the locale transparently parsed into the corresponding datatype, maybe a Date should be returned if the user omits the time, or there should be an option if it is save to assume default values for omitted parts.

@clemens
Owner
clemens commented May 25, 2012

A year has passed – have we made up our minds about this? :)

@SKoschnicke

In any case there needs to be a way for the application to know if the user input was invalid. I would vote for disabling the return of defaults and giving an error instead on invalid user input and making the current behavior optional.

@sobrinho

@clemens I think we can close this due to lack of activity (IMO this shouldn't be on delocalise).

@clemens
Owner
clemens commented Nov 11, 2015

Agreed.

@clemens clemens closed this Nov 11, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.