On Mon, 27 Feb 2012 22:00:34 +0900 woohyun<woo_hyun0...@naver.com> said:

> This patch was made by Sumanth Krishna Mannam.
> Please refer following message ~ and attached patch.
> =======================================================
> > first i was strolling along, reading elm_datetime.c... and then i saw:
> > 
> > static int _days_in_month[12] = { 31, 28, 31, 30, 31, 30,
> > 31, 31, 30, 31, 30, 31 };
> > 
> > and then i was like:
> > http://www.youtube.com/watch?v=6FWUjJF1ai0
> >
> > and i saw...
> > if (__isleap(*timearr[ELM_DATETIME_YEAR]) &&
> > 
> > and i was like:
> > http://www.youtube.com/watch?v=fM1O9jWeNoI
> > 
> > (look at clock module src of e17 (in svn trunk/e/src/modules/clock) - in
> > there it manages to draw months and handle month sizes by using syscalls
> > that should get this from a time database and thus be correct. you can
> > figure out the range by using syscalls to do it all look @ _time_eval()).
> I felt array based count is not that bad... and even elm_calendar does the
> same . anyway, I gave a try with your method, using mktime() and check for
> month wraaping and then deciding. Patch is updated accordingly . 

http://www.corkscrew-balloon.com/travel/9812paris/leap.html

leap years do not make feb have 29 days EVERY 4 year. there are oddities to
this over history and probably will be in the future too. thats the pont of the
system time "database" and "apis" to figure out so you dont have to :)

> > limits for years.. why 1970->2037? that seems a bit silly to limit it -
> > what if i'm entering the date of birth of my father? it's definitely before
> > 1970 :)
> I made 1970 as the default limit based on Epoc time 1970.
> I have no issues to make default limit to further lowest :) I changed the
> limits to 1900 & 2037. 

why not just allow ANY date ... no limits? what if someone uses the widget for
a historcal event "Examination app" that asks students when events happened in
history...

> > and then i was looking at api:
> > 
> > Elm_Datetime_FieldType -> Elm_Datetime_Field_Type
> > 
> > otherwise i shall not quibble about api :)
> Yep...renamed to Elm_Datetime_Field_Type.
> Sign-Off By: Sumanth M.V.K &lt;sumant...@samsug.com&gt;
> Thank You,
> Regards,
> Sumanth

cool - fix the above limit. it dont like it. for at least 1 reason given above.
other than that take note of that page on leap years and just do some research
yourself about time and how humans have, over history, defined it, written it
down, played with it, adjusted it and tried to make your time system match the
natural world around us. it'll encourage you to just piggy-back on someone
elses time api so you dont have to re-do all the work.. and if there is a bug -
its fixed in 1 place for everyone.

> -----Original Message-----
> From: "Carsten Haitzler"&lt;ras...@rasterman.com&gt; 
> To: "Enlightenment developer
> list"&lt;enlightenment-devel@lists.sourceforge.net&gt; Cc:
> "csm...@samsung.com"&lt;csm...@samsung.com&gt;;
> "enlightenment-devel&lt;enlightenment-devel"@lists.sourceforge.net;&gt;;
> "SHAJI SIVANANDAN"&lt;shaj...@samsung.com&gt;; "Sumanth Krishna
> Mannam"&lt;sumant...@samsung.com&gt; Sent: 12-02-24(금) 20:34:56 Subject: Re:
> [E-devel] [Patch] Elementary : New widget Elm_datetime patch On Fri, 17 Feb
> 2012 08:21:30 +0000 (GMT) Sumanth Krishna Mannam
> &lt;sumant...@samsung.com&gt; said: first i was strolling along, reading
> elm_datetime.c... and then i saw: static int _days_in_month[12] = { 31, 28,
> 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }; and then i was like:
> http://www.youtube.com/watch?v=6FWUjJF1ai0 and i saw...
>  if (__isleap(*timearr[ELM_DATETIME_YEAR]) &&
> and i was like:
>  http://www.youtube.com/watch?v=fM1O9jWeNoI
> (look at clock module src of e17 (in svn trunk/e/src/modules/clock) - in there
> it manages to draw months and handle month sizes by using syscalls that should
> get this from a time database and thus be correct. you can figure out the
> range by using syscalls to do it all look @ _time_eval()).
> limits for years.. why 1970->2037? that seems a bit silly to limit it - what
> if i'm entering the date of birth of my father? it's definitely before 1970 :)
> and then i was looking at api:
> Elm_Datetime_FieldType -> Elm_Datetime_Field_Type
> otherwise i shall not quibble about api :)
> > Hi All,
> > 
> > Attached to the mail is the patch for new elementary widget elm_datetime.
> > Refer to the below EFL post history for more details. 
> > 
> > The datetime widget provides an option to display Date & time based on
> > current locale format and the user can edit them through dynamic Modules.
> > Dynamic modules can be based on 1. Content Popup/diskselector based list 2.
> > Elm_entry with ISE based input 3. Elm_Spinner based etc. Refer to the
> > Screenshots: &lt;1.ctxpopup_diskselector_UI> &lt;2.entry_ise_UI>
> > &lt;3.spinner_selection_UI>
> > 
> > Can someone review and push this patch to EFL repository?
> > 
> > Change description:
> > New widget Elm_datetime is added.
> > Datetime widget displays the Date &Time fields and provides a customizable
> > way to edit them. The widget is implemented in a modular fashion for
> > date/time field inputs. Ctxpopup based input is proposed as the default
> > selection module. Localization support based on Libc is also supported.
> > 
> > Sign-Off By: Sumanth M.V.K &lt;sumant...@samsug.com&gt;
> > 
> > 
> > Thank you,
> > 
> > Regards,
> > Sumanth M.V.K
> > 
> > ------------------------------------------------------------------------------
> > 
> > Re: [E-devel] Lib ICU Integration
> > Tom Hacohen
> > Fri, 23 Sep 2011 01:12:16 -0700
> > 
> > On 23/09/11 11:05, Govindaraju SM wrote:
> > > ==> You have to wait a little while to make widget patch with proper 
> > > documentation, examples :)
> > 
> > Hehe, sure, Rome was not built in a day. :)
> > 
> > --
> > Tom.
> > 
> > ------------------------------------------------------------------------------
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > -----Original Message----- 
> > From: Tom Hacohen
> > Sent: Thursday, September 22, 2011 7:41 PM
> > To: Govindaraju SM
> > Cc: Enlightenment developer list
> > Subject: Re: [E-devel] Lib ICU Integration
> > 
> > On 22/09/11 13:01, Govindaraju SM wrote:
> > > ==> Thanks for your suggestion. I can very much do with libc with out
> > > ICU for date formatting, including getting locale strings.
> > > ICU integration is dropped.. :)
> > 
> > I'm glad we agree. :)
> > > okay, Why this should widget? I have to display a Date and/or Time in
> > > the single line ( as usual date/time display )
> > > and able to edit it without launching a calendar or other time edit
> > > widget. This new widget does it,
> > > Displays date and allows to edit individual fields.
> > 
> > I don't get an exact visual, I guess I'll have to wait until you finish.
> > 
> > > ==> If it is just date/time display, then your point is very much
> > > agreeable.
> > > But this new widget provides option to edit individual fields also
> > > without launching Calendar.
> > > ( mainly for optimal usage of screen space and change date without too
> > > many clicks )
> > 
> > I don't quite understand, so I guess I'll have to wait until you finish
> > to give a proper response. In the meanwhile, from what I understand, it
> > sounds cool.
> > --
> > Tom.
> > 
> > ==> You have to wait a little while to make widget patch with proper 
> > documentation, examples :)
> > 
> > Regards,
> > Govind
> > 
> > ____________________________________________
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > Re: [E-devel] Lib ICU Integration
> > Tom Hacohen
> > Thu, 22 Sep 2011 03:41:18 -0700
> > 
> > On 22/09/11 13:01, Govindaraju SM wrote:
> > > ==> Thanks for your suggestion. I can very much do with libc with out
> > > ICU for date formatting, including getting locale strings.
> > > ICU integration is dropped.. :)
> > 
> > I'm glad we agree. :)
> > > okay, Why this should widget? I have to display a Date and/or Time in
> > > the single line ( as usual date/time display )
> > > and able to edit it without launching a calendar or other time edit
> > > widget. This new widget does it,
> > > Displays date and allows to edit individual fields.
> > 
> > I don't get an exact visual, I guess I'll have to wait until you finish.
> > 
> > > ==> If it is just date/time display, then your point is very much
> > > agreeable.
> > > But this new widget provides option to edit individual fields also
> > > without launching Calendar.
> > > ( mainly for optimal usage of screen space and change date without too
> > > many clicks )
> > 
> > I don't quite understand, so I guess I'll have to wait until you finish 
> > to give a proper response. In the meanwhile, from what I understand, it 
> > sounds cool.
> > --
> > Tom.
> > 
> > ------------------------------------------------------------------------------
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > Re: [E-devel] Lib ICU Integration
> > Govindaraju SM
> > Thu, 22 Sep 2011 03:04:33 -0700
> > 
> > -----Original Message----- 
> > From: Tom Hacohen
> > Sent: Sunday, September 18, 2011 2:26 PM
> > To: Govindaraju SM
> > Cc: Enlightenment developer list
> > Subject: Re: [E-devel] Lib ICU Integration
> > 
> > On 16/09/11 04:44, Govindaraju SM wrote:
> > > ==> Requirement is providing Date & time input widget which should
> > > change the format automatically based on current system locale,
> > > also display the date field strings in the locale specific language. so,
> > > at this moment ICU lib utilization is only for date & time formatting,
> > > locale and resource bundle.
> > > based on our experiment, performance overhead added by ICU is
> > > negligible. Binary size and its RAM usage, your point is right, due to
> > > extensive features supported
> > > by ICU. But I see some more features can be utilized, like locale
> > > specific number format, currency, regular expressions, any locale Word
> > > boundary calculation etc...
> > 
> > strftime with "%c" gives you the time based on locale including
> > translation, ordering and everything. But even if it wasn't the case, it
> > should be done in the user app and not in the widget toolkit.
> > 
> > ==> Thanks for your suggestion. I can very much do with libc with out ICU 
> > for date formatting, including getting locale strings.
> > ICU integration is dropped.. :)
> > okay, Why this should widget? I have to display a Date and/or Time 
> > in the single line ( as usual date/time display )
> > and able to edit it without launching a calendar or other time edit 
> > widget. This new widget does it,
> > Displays date and allows to edit individual fields.
> > 
> > > ==> Get the locale specific formats, formatted date with locale specific
> > > strings, context specific field limits ( ex, whats the max date value
> > > for the specified month/year )
> > > plus, the resource bundle should be replicated into gettext. Number
> > > formatting, regex are some of the features can be utilized later.
> > 
> > All this logic should be done in the app and presented in widgets as
> > wanted, to reason to put that logic in elm.
> > 
> > > ==> Idea is to make a simple date & time input widget. ( calendar widget
> > > occupies more screen space, need simple widget ). Thank you for your 
> > > input.
> > > Do you think integrating ICU is okay if, we utilize all the above
> > > mentioned features?
> > 
> > I still disagree because the reasons mentioned above. This shouldn't be
> > a widget, and even if it was a widget, I doubt it really needs ICU to
> > operate (but that's not the important part, the important part is that
> > it shouldn't be a widget in my opinion).
> > 
> > ==> If it is just date/time display, then your point is very much agreeable.
> > But this new widget provides option to edit individual fields also without 
> > launching Calendar.
> > ( mainly for optimal usage of screen space and change date without too many 
> > clicks )
> > --
> > Tom.
> > ------------------------------------------------------------------------------
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > Re: [E-devel] Lib ICU Integration
> > Tom Hacohen
> > Sat, 17 Sep 2011 22:26:56 -0700
> > 
> > On 16/09/11 04:44, Govindaraju SM wrote:
> > > ==> Requirement is providing Date & time input widget which should
> > > change the format automatically based on current system locale,
> > > also display the date field strings in the locale specific language. so,
> > > at this moment ICU lib utilization is only for date & time formatting,
> > > locale and resource bundle.
> > > based on our experiment, performance overhead added by ICU is
> > > negligible. Binary size and its RAM usage, your point is right, due to
> > > extensive features supported
> > > by ICU. But I see some more features can be utilized, like locale
> > > specific number format, currency, regular expressions, any locale Word
> > > boundary calculation etc...
> > 
> > strftime with "%c" gives you the time based on locale including 
> > translation, ordering and everything. But even if it wasn't the case, it 
> > should be done in the user app and not in the widget toolkit.
> > 
> > > ==> Get the locale specific formats, formatted date with locale specific
> > > strings, context specific field limits ( ex, whats the max date value
> > > for the specified month/year )
> > > plus, the resource bundle should be replicated into gettext. Number
> > > formatting, regex are some of the features can be utilized later.
> > 
> > All this logic should be done in the app and presented in widgets as 
> > wanted, to reason to put that logic in elm.
> > 
> > > ==> Idea is to make a simple date & time input widget. ( calendar widget
> > > occupies more screen space, need simple widget ). Thank you for your
> > > input. Do you think integrating ICU is okay if, we utilize all the above
> > > mentioned features?
> > 
> > I still disagree because the reasons mentioned above. This shouldn't be 
> > a widget, and even if it was a widget, I doubt it really needs ICU to 
> > operate (but that's not the important part, the important part is that 
> > it shouldn't be a widget in my opinion).
> > --
> > Tom.
> > 
> > ------------------------------------------------------------------------------
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > Re: [E-devel] Lib ICU Integration
> > Govindaraju SM
> > Thu, 15 Sep 2011 18:46:40 -0700
> > 
> > Dear Tom,
> > 
> > -----Original Message----- 
> > From: Tom Hacohen
> > Sent: Wednesday, September 14, 2011 2:15 PM
> > To: Enlightenment developer list
> > Cc: Govindaraju SM ; Sumanth
> > Subject: Re: [E-devel] Lib ICU Integration
> > 
> > On 14/09/11 05:39, Govindaraju SM wrote:
> > > Hello All,
> > >
> > > We are considering lib ICU integration ( 
> > > http://icu-project.org/apiref/icu4c/ ) with EFL to enhance the 
> > > localization support.
> > >
> > > Initially, Date& time input / display with ucal, udat, uloc features.
> > > ICU provides API to get default system Locale ( or user specified ) 
> > > specific date and time layout formats ( “ddMMyyyy hh:mm a”, “MMddyyyy 
> > > HH:mm” , “yyyyMMdd hh:mm a” etc ), locale specific formatted strings, 
> > > context based field limit ( Feb –28, Leap yr Feb –29 etc ).
> > >
> > > Pls provide your thought on this.
> > >
> > 
> > I'm not sure it's wanted. From what I hear/have seen, ICU is fat and
> > bloated; That's why I chose using the libraries I chose when
> > implementing the unicode-related text features, e.g, fribidi, harfbuzz,
> > liblinebreak, which are considered lighter, faster and better designed.
> > 
> > ==> Requirement is providing Date & time input widget which should change 
> > the format automatically based on current system locale,
> > also display the date field strings in the locale specific language. so, at 
> > this moment ICU lib utilization is only for date & time formatting, locale 
> > and resource bundle.
> > based on our experiment, performance overhead added by ICU is negligible. 
> > Binary size and its RAM usage, your point is right, due to extensive 
> > features supported
> > by ICU. But I see some more features can be utilized, like locale specific 
> > number format, currency, regular expressions, any locale Word boundary 
> > calculation etc...
> > 
> > The real question is what do you feel you can't do with just
> > locale/strftime. I'd like to see more information on what you are trying
> > to achieve instead of how (ICU integration).
> > 
> > ==> Get the locale specific formats, formatted date with locale specific 
> > strings, context specific field limits ( ex, whats the max date value for 
> > the specified month/year )
> > plus, the resource bundle should be replicated into gettext. Number 
> > formatting, regex are some of the features can be utilized later.
> > 
> > Furthermore, what does this "integration" include? What do you plan on
> > doing?
> > 
> > ==> Idea is to make a simple date & time input widget. ( calendar widget 
> > occupies more screen space, need simple widget ). Thank you for your input.
> > Do you think integrating ICU is okay if, we utilize all the above mentioned 
> > features?
> > 
> > In my opinion this is not needed at best, and should probably be
> > avoided. With that being said, my opinions are based on the little
> > information you provided. Please provide more information.
> > 
> > Thanks,
> > Tom.
> > -----------
> > Regards,
> > Govind 
> > 
> > ------------------------------------------------------------------------------
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > Re: [E-devel] Lib ICU Integration
> > Tom Hacohen
> > Tue, 13 Sep 2011 22:15:41 -0700
> > 
> > On 14/09/11 05:39, Govindaraju SM wrote:
> > > Hello All,
> > >
> > > We are considering lib ICU integration
> > > ( http://icu-project.org/apiref/icu4c/ ) with EFL to enhance the
> > > localization support.
> > >
> > > Initially, Date& time input / display with ucal, udat, uloc features.
> > > ICU provides API to get default system Locale ( or user specified )
> > > specific date and time layout formats ( “ddMMyyyy hh:mm a”, “MMddyyyy
> > > HH:mm” , “yyyyMMdd hh:mm a” etc ), locale specific formatted strings,
> > > context based field limit ( Feb –28, Leap yr Feb –29 etc ).
> > >
> > > Pls provide your thought on this.
> > >
> > 
> > I'm not sure it's wanted. From what I hear/have seen, ICU is fat and 
> > bloated; That's why I chose using the libraries I chose when 
> > implementing the unicode-related text features, e.g, fribidi, harfbuzz, 
> > liblinebreak, which are considered lighter, faster and better designed.
> > 
> > The real question is what do you feel you can't do with just 
> > locale/strftime. I'd like to see more information on what you are trying 
> > to achieve instead of how (ICU integration).
> > 
> > Furthermore, what does this "integration" include? What do you plan on 
> > doing?
> > 
> > In my opinion this is not needed at best, and should probably be 
> > avoided. With that being said, my opinions are based on the little 
> > information you provided. Please provide more information.
> > 
> > Thanks,
> > Tom.
> > ------------------------------------------------------------------------------
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> -- 
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler) ras...@rasterman.com
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ras...@rasterman.com


------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to