1. Standard library - date and time
- Posted by Jeremy Cowgar <jeremy at cow?ar.?om> Apr 21, 2008
- 1124 views
- Last edited Apr 22, 2008
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? -- Jeremy Cowgar http://jeremy.cowgar.com
2. Re: Standard library - date and time
- Posted by gshingles <gshingles at gma??.com> Apr 21, 2008
- 1082 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
3. Re: Standard library - date and time
- Posted by c.k.lester <euphoric at cklester?co?> Apr 21, 2008
- 1092 views
- Last edited Apr 22, 2008
Jeremy Cowgar wrote: > > 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? Euphoria's current date() function returns date and time. Euphoria's current time() function returns elapsed time. datetime() could replace date(), although not perfectly (datetime() returns two sequences instead of 6 elements). time() could be replaced by etime() (for "elapsed time"), so then time() could return the actual system time(?). 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.
4. Re: Standard library - date and time
- Posted by Jeremy Cowgar <jeremy at cowg?r.co?> Apr 22, 2008
- 1074 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
5. Re: Standard library - date and time
- Posted by c.k.lester <euphoric at ck?ester.?om> Apr 22, 2008
- 1077 views
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?
6. Re: Standard library - date and time
- Posted by Julio C. Galaret Viera <galaret at ?dinet.com.uy> Apr 22, 2008
- 1081 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
7. Re: Standard library - date and time
- Posted by c.k.lester <euphoric at cklester.c??> Apr 22, 2008
- 1085 views
Julio C. Galaret Viera wrote: > > I think the name "nowDateTime()" is redundant. I suggest "now()" as in other > languages. Ha! Good point. :)
8. Re: Standard library - date and time
- Posted by Jeremy Cowgar <jeremy at ?owgar.co?> Apr 22, 2008
- 1079 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
9. Re: Standard library - date and time
- Posted by Mike777 <anon4321 at g??il.com> Apr 22, 2008
- 1063 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}} 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
10. Re: Standard library - date and time
- Posted by yuku <yuku at ikite?.?om> Apr 22, 2008
- 1065 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_*.
11. Re: Standard library - date and time
- Posted by Shawn Pringle <shawn.pringle at g?ail.?om> Apr 22, 2008
- 1080 views
Lets not force people to reedit their code by using names in the include files distributed with the interpreter itself. The function date is a builtin command! I never liked how these commands count from 1900 but it is better to use new names than old ones. My 2 cents. Shawn Pringle
12. Re: Standard library - date and time
- Posted by Jeremy Cowgar <jeremy at cowg?r?com> Apr 22, 2008
- 1086 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
13. Re: Standard library - date and time
- Posted by c.k.lester <euphoric at ?kles?er.com> Apr 22, 2008
- 1094 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}} 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. :)
14. Re: Standard library - date and time
- Posted by Julio C. Galaret Viera <galaret at adine?.co?.uy> Apr 22, 2008
- 1178 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
15. Re: Standard library - date and time
- Posted by c.k.lester <euphoric at cklest?r.com> Apr 22, 2008
- 1078 views
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.
16. Re: Standard library - date and time
- Posted by Jeremy Cowgar <jeremy at cowgar??om> Apr 22, 2008
- 1068 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
17. Re: Standard library - date and time
- Posted by c.k.lester <euphoric at ckleste??com> Apr 22, 2008
- 1085 views
Jeremy Cowgar wrote: > 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? 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.
18. Re: Standard library - date and time
- Posted by yuku <yuku at ikitek.co?> Apr 22, 2008
- 1070 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
19. Re: Standard library - date and time
- Posted by c.k.lester <euphoric at ckles?er.co?> Apr 22, 2008
- 1068 views
yuku wrote: > > The prefix is datetime_ (should it be date_ ? but since the type name > is datetime, will it confuse users?) Please, no prefix. Unless you're going to create a Euphoria IDE with intellisense. :) I thought Matt said namespacing would take care of this anyway...
20. Re: Standard library - date and time
- Posted by Jeremy Cowgar <jeremy at cow?ar.?om> Apr 22, 2008
- 1071 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
21. Re: Standard library - date and time
- Posted by yuku <yuku at ik?tek.?om> Apr 22, 2008
- 1070 views
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. Reasons: - this is Euphoria (simple!) not perl or some other complicated languages - why would someone use time type? It is just a bunch of seconds grouped in 60 and 60*60. No difficult math there. - even Java only have Date (which is date + time), no Time or specific Date - having date type does not speed calculation, only difference with datetime is there is no need to multiply with 86400 - we don't need to break existing codes by using "date" and "time" for type names or function names (important!)
22. Re: Standard library - date and time
- Posted by c.k.lester <euphoric at ckleste?.co?> Apr 22, 2008
- 1085 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?
23. Re: Standard library - date and time
- Posted by Jeremy Cowgar <jeremy at cow?ar.com> Apr 22, 2008
- 1080 views
yuku wrote: > > Reasons: > - this is Euphoria (simple!) not perl or some other complicated languages > - why would someone use time type? It is just a bunch of seconds grouped in > 60 and 60*60. No difficult math there. > - even Java only have Date (which is date + time), no Time or specific Date > - having date type does not speed calculation, only difference with datetime > is there is no need to multiply with 86400 > - we don't need to break existing codes by using "date" and "time" for type > names or function names (important!) 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? -- Jeremy Cowgar http://jeremy.cowgar.com
24. Re: Standard library - date and time
- Posted by Jeremy Cowgar <jeremy at c?w?ar.com> Apr 22, 2008
- 1080 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
25. Re: Standard library - date and time
- Posted by yuku <yuku at ikitek.c??> Apr 22, 2008
- 1063 views
c.k.lester wrote: > 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? In the lib. Keep euphoria have 4 types atom integer object sequence. Yes, I also think that types are not necessary, but nevertheless we use types there for error checking. User and eu2c can use without type_check for performance. Types are also used in file.e and Rob's standard library. Probably (still probably) datetime will be more efficient using atom as the internal representation than {year, month, date}.
26. Re: Standard library - date and time
- Posted by yuku <yuku at iki??k.com> Apr 22, 2008
- 1079 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?
27. Re: Standard library - date and time
- Posted by Jeremy Cowgar <jeremy at c?wgar.c?m> Apr 22, 2008
- 1074 views
yuku wrote: > (the implementation is not done, waiting for the permission as mentioned > above). Carl just emailed me back: "I'd be absolutely honoured if DateTime made it into the official Euphoria distribution..." He did not say it was OK to change the copyright like I asked, so I have returned an email asking him specifically about that again, but from his total email, I think he will say yes, but we need to make sure. He also said that what is on The Archive is not the latest copy. He said please download the latest copy from: http://www.phodd.net/cyrek/euphoria/ -- Jeremy Cowgar http://jeremy.cowgar.com
28. Re: Standard library - date and time
- Posted by Matt Lewis <matthewwalkerlewis at ?mail.?om> Apr 22, 2008
- 1083 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
29. Re: Standard library - date and time
- Posted by Jeremy Cowgar <jeremy at cowgar.?o?> Apr 22, 2008
- 1087 views
Jeremy Cowgar wrote: > > yuku wrote: > > (the implementation is not done, waiting for the permission as mentioned > > above). > > Carl just emailed me back: > > "I'd be absolutely honoured if DateTime made it into the official Euphoria > distribution..." > Carl gave the OK for using, changing the copyright, so, Thank you Carl! It's a go w/using the datetime functions from the lib. -- Jeremy Cowgar http://jeremy.cowgar.com
30. Re: Standard library - date and time
- Posted by Shawn Pringle <shawn.pringle at gmail.c?m> Apr 23, 2008
- 1066 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
31. Re: Standard library - date and time
- Posted by CChris <christian.cuvier at ?gricu?ture.gouv.fr> Apr 23, 2008
- 1105 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. > > -- 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 I don't use these routines much, so I won't comment on the list. Prefixes should be as short as possible, as the language is already quite "typose". Make it dt_ for instance. Another route would be to allow defining aliases, so that any programer could rename clumsy names.
alias datetime_datetime_to_date dt2d
would be more efficient than
function dt2d(args) return datetime_datetime_to_date(args) end function
CChis