OpenEuphoria

2. Re: Standard library - date and time

• Posted by gshingles <gshingles at gma??.com> Apr 21, 2008
• 1080 views
• Last edited Apr 22, 2008

Jeremy Cowgar wrote:
> 
> The best library I have found for date and time handling is datetime.zip in
> the archive (by Carl White). It, however, is not directly compatible with the
> existing date() function. date() returns {year, month, day, hour, minute,
> second,
> day of week, day of year} while datetime.zip uses 3 over all types, date
> {year,
> month, day}, time {hour, minute, second} and datetime {{year, month, day},
> {hour,
> minute, second}}.
> 
> This allows for handling just dates or just times or both. It does have it's
> own date() type functions.
> 
> What do you think? Should new functions be created to add/subtract dates and
> times be created to have compatibility with the existing date() function or
> use Carl's library that uses three types? There is benefit to this as many
> times
> you do not need to represent the time portion, date portion or day of week,
> day of year. Thus, with Carl's library, you can have only what you want saving
> memory/complexity.
> 
> Any thoughts?

Hi Jeremy

I am a lurker on the forum, I don't do a lot with Euphoria these days but
when I do half my development time is taken up sourcing standard functionality,
so I applaud your effort with the standardisation.

I think DateTime is very complete, well thought out, and accurate. I just had
a look through my projects folders and it is in every project, so that is a
good indication to me that it should be standard, I don't know about anyone
else.

I rarely use Euphoria's date function as DateTime has nowDateTime() etc. So
I would include it (with the author's permission of course) and worry about
any interface with Euphoria date() as and when it becomes necessary.

Just to throw another cat into the development bag, Perl has a nifty ability
to know what a caller wants when a function is called.

So for example if you want a scalar date (ie formatted string) you call the
time function with a scalar eg (excuse perlese):

$now_string = localtime();  # e.g., "Thu Oct 13 04:54:34 1994"

but if you want the component parts a la Euphoria date you
call it with an array or list on the left hand side, eg:

($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime();

The localtime function knows whether to return a scalar or a list and does
so appropriately. This might be a handy ability for Euphoria at some stage,
but it may as well be enhanced given the complexity of sequences and strings
being sequences. But it could be as "simple" as knowing the calling type on
the lhs of an assignment, eg:

if wants(atom) then return 0 elsif wants(DateTime) return {{},{}} end if...
 etc.

Gary

4. Re: Standard library - date and time

• Posted by Jeremy Cowgar <jeremy at cowg?r.co?> Apr 22, 2008
• 1072 views

c.k.lester wrote:
> 
> I don't think I'd have a problem with any of these changes if there were
> increases in speed and ease-of-use/utility. You would probably need to
> emulate the old date() and time() functions (in something like old_date() and
> old_time()) so dependent code could be easily modified.

I wouldn't get rid of the current date() function. This would just be in
addition to the date() function.

--
Jeremy Cowgar
http://jeremy.cowgar.com

6. Re: Standard library - date and time

• Posted by Julio C. Galaret Viera <galaret at ?dinet.com.uy> Apr 22, 2008
• 1079 views

c.k.lester wrote:
> 
> Jeremy Cowgar wrote:
> > c.k.lester wrote:
> > > I don't think I'd have a problem with any of these changes if there were
> > > increases in speed and ease-of-use/utility. You would probably need to
> > > emulate the old date() and time() functions (in something like old_date()
> > > and
> > > old_time()) so dependent code could be easily modified.
> > I wouldn't get rid of the current date() function. This would just be in
> > addition
> > to the date() function.
> 
> Well, it might be a change for the better to have
> 
> date() - returns date {yr,mo,da}
> time() - returns current system time {hh,mm,ss,ms}
> nowDateTime() - how date() works now
> etime() - returns elapsed time (emulates current time() behavior)
> 
> The above would be added to the interpreter. The following would be in a
> library.
> 
> datetime() - returns {date(),time()} (this is redundant so I would put it in
> a library)
> +all other date/time functions
> 
> Why not?

I think the name "nowDateTime()" is redundant. I suggest "now()" as in other
languages.

JG

8. Re: Standard library - date and time

• Posted by Jeremy Cowgar <jeremy at ?owgar.co?> Apr 22, 2008
• 1077 views

Julio C. Galaret Viera wrote:
> 
> I think the name "nowDateTime()" is redundant. I suggest "now()" as in other
> languages.
> 

Except we are dealing with three types. does now() mean now() as in time?
{7,1,54} or now() as in date? {2008, 4, 22} or now() as in date and time?
{{2008,4,22}, {7,1,54}}

--
Jeremy Cowgar
http://jeremy.cowgar.com

10. Re: Standard library - date and time

• Posted by yuku <yuku at ikite?.?om> Apr 22, 2008
• 1064 views

Mike777 wrote:
> 
> Jeremy Cowgar wrote:
> > 
> > Julio C. Galaret Viera wrote:
> > > 
> > > I think the name "nowDateTime()" is redundant. I suggest "now()" as in
> > > other
> > > languages.
> > > 
> > 
> > Except we are dealing with three types. does now() mean now() as in time?
> > {7,1,54}
> > or now() as in date? {2008, 4, 22} or now() as in date and time?
> > {{2008,4,22},
> > {7,1,54}}
> 
> True, but now() as all encompassing is frequently used.  In the absence of
> clarification
> I would expect now() to provide what is described above as nowDateTime(). 
> 
> Mike

I think date and time library consists of many functions. Shouldn't we make it
prefixed, like date_now()?
We have a lot of functions such as subtract, add, get second, get weekday, to
unix, possibly some routines to do with timezones, etc. If we don't prefix it, we
will encumber the namespace. Actual prefixing examples are the task_* routines
and the new map_*.

12. Re: Standard library - date and time

• Posted by Jeremy Cowgar <jeremy at cowg?r?com> Apr 22, 2008
• 1084 views

I agree with a few points made.

1. Let's not change the existing date() and time() functions. We are adding to
the standard library, not redesigning it. If there was a major flaw, that may be
different, but date() currently provides information than many applications rely
on and it will provide all the information that many people need. As time
progresses, it may become used less and less and maybe at that time we can visit
the idea of deprecating it (if that time comes).

2. We should prefix some things. For instance, the map functions deal with maps
and task function deal with tasks. They are very specific and are not generic
functions such as, min, max, remove, etc... I think date_now(), datetime_now()
makes sense. For instance, we may be date_to_seconds() and also
time_to_seconds(). We *need* to prefix those for them to make sense. to_seconds()
... how would it know if it's working on a date, time or both?

I have found three email addresses for Carl (author of datetime) and have sent
an email asking if it could be included in Euphoria. datetime has a copyright
statement and no released license.

--
Jeremy Cowgar
http://jeremy.cowgar.com

14. Re: Standard library - date and time

• Posted by Julio C. Galaret Viera <galaret at adine?.co?.uy> Apr 22, 2008
• 1176 views

Jeremy Cowgar wrote:
> 
> Julio C. Galaret Viera wrote:
> > 
> > I think the name "nowDateTime()" is redundant. I suggest "now()" as in other
> > languages.
> > 
> 
> Except we are dealing with three types. does now() mean now() as in time?
> {7,1,54}
> or now() as in date? {2008, 4, 22} or now() as in date and time? {{2008,4,22},
> {7,1,54}}
> 
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>

now() is now! so it should returns year, month, day, hour, minute, second like,
for example, in MySQL (2008-04-22 14:33:20)

Since it won't replace date(), it will not break any code except. Anyway, the
earlier code is broken the better.

JG

16. Re: Standard library - date and time

• Posted by Jeremy Cowgar <jeremy at cowgar??om> Apr 22, 2008
• 1067 views

c.k.lester wrote:
> 
> Julio C. Galaret Viera wrote:
> > 
> > Anyway, the earlier code is broken the better.
> 
> This is what I meant to convey. If the code is going to break "eventually,"
> now is better than later.

The code is broken? How? Why does it need broken?

--
Jeremy Cowgar
http://jeremy.cowgar.com

18. Re: Standard library - date and time

• Posted by yuku <yuku at ikitek.co?> Apr 22, 2008
• 1068 views

Jeremy Cowgar wrote:
> 1. Let's not change the existing date() and time() functions. We are adding
> to the standard library, not redesigning it. 
> 
> 2. We should prefix some things. For instance, the map functions deal with
> maps
> and task function deal with tasks.
> 
> I have found three email addresses for Carl (author of datetime) and have sent
> an email asking if it could be included in Euphoria. datetime has a copyright
> statement and no released license.

Hi,

I committed the prototype of datetime functions by adhering to the points
above.
We defined a new type: datetime (the implementation is not done, waiting
for the permission as mentioned above).
The prefix is datetime_ (should it be date_ ? but since the type name
is datetime, will it confuse users?)

To maintain compatibility with built-in date(), the datetime object
can be created using datetime_from_date(). 
The now function is named datetime_now().

Here are the function prototypes (some C-style for clarity).
Please give suggestions etc.

-- Date and Time functions
-- 2008
-- note 2008-04-23: ONLY CONTAINS FUNCTION PROTOTYPES
-- No timezone offset.

-- global type datetime(object o)

-- datetime datetime_new(int year, int month, int date, int hour, int minute,
int second)
-- Creates the datetime object for the specified parameters

-- int datetime_compare(datetime dt1, datetime dt2)
-- Compare the receiver to the specified Date to determine the relative
ordering.
-- returns -1 or 0 or 1

-- datetime datetime_from_date(object date)
-- Converts the built-in date() format to datetime format

-- datetime datetime_now()
-- Returns the datetime object for now. No timezones!

-- int 	datetime_get_hour(datetime dt)
-- Answers the gregorian calendar hour of the day. 

-- int 	datetime_get_minute(datetime dt)
-- Answers the gregorian calendar minute of the hour. 

-- int 	datetime_get_second(datetime dt)
-- Answers the gregorian calendar second of the minute. 

-- int 	datetime_get_year()
-- Answers the gregorian calendar year since 1900. 

-- int 	datetime_get_month(datetime dt)
-- Answers the gregorian calendar month. 

-- int datetime_get_date(datetime dt)
-- Answers the gregorian calendar day of the month. 

-- int 	datetime_get_day(datetime dt)
-- Answers the gregorian calendar day of the week. 

-- datetime  datetime_set_hour(integer dt)
-- Sets the gregorian calendar hour of the day. 
global function datetime_set_hour(integer dt)

-- datetime  datetime_set_minute(int dt)
-- Sets the gregorian calendar minute of the hour. 

-- datetime  datetime_set_second(int dt)
-- Sets the gregorian calendar second of the minute. 

-- datetime  datetime_set_year()
-- Sets the gregorian calendar year since 1900. 

-- datetime  datetime_set_month(datetime dt)
-- Sets the gregorian calendar month. 

-- datetime datetime_set_date(datetime dt)
-- Sets the gregorian calendar day of the month. 

-- datetime datetime_parse(ustring string)
-- parse the string and returns the datetime

-- ustring datetime_format(ustring format)
-- format the date according to the format string
-- format string some taken from date(1)
--  %%     a literal %
--  %a     locale's abbreviated weekday name (e.g., Sun)
--  %A     locale's full weekday name (e.g., Sunday)
--  %b     locale's abbreviated month name (e.g., Jan)
--  %B     locale's full month name (e.g., January)
--  %C     century; like %Y, except omit last two digits (e.g., 21)
--  %d     day of month (e.g, 01)
--  %g     last two digits of year of ISO week number (see %G)
--  %H     hour (00..23)
--  %I     hour (01..12)
--  %j     day of year (001..366)
--  %k     hour ( 0..23)
--  %l     hour ( 1..12)
--  %m     month (01..12)
--  %M     minute (00..59)
--  %p     locale's equivalent of either AM or PM; blank if not known
--  %P     like %p, but lower case
--  %s     seconds since 1970-01-01 00:00:00 UTC
--  %S     second (00..60)
--  %u     day of week (1..7); 1 is Monday
--  %w     day of week (0..6); 0 is Sunday
--  %y     last two digits of year (00..99)
--  %Y     year

-- atom datetime_to_unix(datetime dt)
-- returns the number of seconds since 1970-1-1 0:0 (no timezone!)

-- datetime datetime_add_second(datetime dt, atom seconds)
-- adds the date with specified number of seconds

-- datetime datetime_add_day(datetime dt, atom days)
-- adds the date with specified number of days

-- atom datetime_diff_second(datetime dt1, datetime dt2)
-- returns the number of seconds between two datetimes

-- atom datetime_diff_day(datetime dt1, datetime dt2)
-- returns the number of days between two datetimes

20. Re: Standard library - date and time

• Posted by Jeremy Cowgar <jeremy at cow?ar.?om> Apr 22, 2008
• 1069 views

c.k.lester wrote:
> 
> No, it's not broken (yet). I'm saying that we should co-opt date() and time()
> to do what they really should do: give the date and give the time. Yes, that
> will break code, but I think it benefits the language going forward.
>

I think we need to decide. Do we want to have 3 types representing dates and
times? date, time and datetime ?

Also, if so, if we are going to break things, wouldn't the "date" would be
better used as a type instead of a function? same with time and datetime ?

Before breaking anything though, I'd like to have more opinions.

--
Jeremy Cowgar
http://jeremy.cowgar.com

22. Re: Standard library - date and time

• Posted by c.k.lester <euphoric at ckleste?.co?> Apr 22, 2008
• 1083 views

yuku wrote:
> 
> Jeremy Cowgar wrote:
> > I think we need to decide. Do we want to have 3 types representing dates and
> > times? date, time and datetime ?
> 
> I strongly vote for only one type: datetime.

Is this for in a lib or in the interpreter?

A date sequence will be { year:any integer value, month:integer 1-12,
day:integer 1-28|29|30|31 depending on month }

I don't think types are necessary. Would it allow for some optimizations?

24. Re: Standard library - date and time

• Posted by Jeremy Cowgar <jeremy at c?w?ar.com> Apr 22, 2008
• 1079 views

c.k.lester wrote:
> 
> > I strongly vote for only one type: datetime.
> 
> Is this for in a lib or in the interpreter?
> 
> A date sequence will be { year:any integer value, month:integer 1-12,
> day:integer 1-28|29|30|31 depending on month }
> 
> I don't think types are necessary. Would it allow for some optimizations?

It would allow for clearer code and better error checking, for instance:

sequence a
a = {}

add_days(a, 100)

That would fail w/meaningful information. I do not think it does anything for
optimization, if anything, it would slow things down due to type checking? Do I
understand that correctly? However, in your production code you can add without
type_check.

Input?

P.S. Maybe we should get on irc.freenode.org#euphoria! We are using the EUforum
for instant(like) chat!

--
Jeremy Cowgar
http://jeremy.cowgar.com

26. Re: Standard library - date and time

• Posted by yuku <yuku at iki??k.com> Apr 22, 2008
• 1078 views

Jeremy Cowgar wrote:
> You make good points. That, however, means we cannot use datetime.e from the
> archive w/o some work (which it would require anyway due to naming
> conventions).
> It uses 3 types, date, time and datetime. 
> 
> Maybe what we should do is take your template and start filling in functions?

Yes, but we can remove the functions that we don't need, like:

global function DateTimeToDate(DateTime dt) -- returns a Date
    return dt[DT_DATE] -- Warning! Loss of DT_TIME information!
end function

Btw, did you get the permission to use CyrekSoft's code?

28. Re: Standard library - date and time

• Posted by Matt Lewis <matthewwalkerlewis at ?mail.?om> Apr 22, 2008
• 1081 views

yuku wrote:
> 
> Jeremy Cowgar wrote:
> > 1. Let's not change the existing date() and time() functions. We are adding
> > to the standard library, not redesigning it. 
> > 
> > 2. We should prefix some things. For instance, the map functions deal with
> > maps
> > and task function deal with tasks.
> > 
> > I have found three email addresses for Carl (author of datetime) and have
> > sent
> > an email asking if it could be included in Euphoria. datetime has a
> > copyright
> > statement and no released license.
> 
> Hi,
> 
> I committed the prototype of datetime functions by adhering to the points
> above.
> We defined a new type: datetime (the implementation is not done, waiting
> for the permission as mentioned above).
> The prefix is datetime_ (should it be date_ ? but since the type name
> is datetime, will it confuse users?)
> 
> To maintain compatibility with built-in date(), the datetime object
> can be created using datetime_from_date(). 
> The now function is named datetime_now().
> 
> Here are the function prototypes (some C-style for clarity).
> Please give suggestions etc.

<snip>

I think we're going a bit overboard on the prefixing.  As later posts mention,
we should consider refactoring the library, possibly simplifying to reduce
the types.  Are they all even needed?  We might want to split it out into
a date and a time file (I haven't looked at the details, so I'm not sure if
this is a good idea).  Name clashes can be resolved by namespaces, assuming
they happen.  For example:

-- good
   datetime:to_seconds( my_date )
   time:to_seconds( my_time)

   -- less good
   datetime_to_seconds( my_datetime )
   time_to_seconds( my_time )

Matt

30. Re: Standard library - date and time

• Posted by Shawn Pringle <shawn.pringle at gmail.c?m> Apr 23, 2008
• 1065 views

c.k.lester wrote:
> 
> Jeremy Cowgar wrote:
> > Julio C. Galaret Viera wrote:
> > > I think the name "nowDateTime()" is redundant. I suggest "now()" as in
> > > other
> > > languages.
> > Except we are dealing with three types. does now() mean now() as in time?
> > {7,1,54}
> > or now() as in date? {2008, 4, 22} or now() as in date and time?
> > {{2008,4,22},
> > {7,1,54}}
> 
> It should emulate the current date() functionality, IMHO, except provide
> the actual year. I don't want to have to add 1900 to the year anymore. :)

I second the motion: any new routine that has date() functionality should
just send the actual year.  The need for giving years since 1900 to save
memory had already been gone when Euphoria first came out.  Years since
1900 belong with with single letter variable names and gosub.

Shawn Pringle