Re: Re: Need for Date-object

Hello, Erik Hjortsberg wrote: > > At 14:32 2001-07-17 -0300, you wrote: > >Hello, > > > >Erik Hjortsberg wrote: > > > > > > I always find it a hassle to use date and time data in my php applications. > > > One have to convert and parse between mktime() and date() and have to keep > > > track of different parameters and different formats. > > > This is due to php absent handling of atomic dates, ie. objects. Treating > > > them as strings is not very efficient code-wise. > > > >I don't quite agree. You can use the ISO-8601 format (YYYY-MM-DD > >HH:MM:SS) and you can do a lot of operations without converting to > >integers. For instance, you can use strcmp() to compare two dates and it > >will tell you if they are equal or which of them is older. > > > >Using integers has it downside because if you use some of available PHP > >functions you are limited to ranges between 1970 and 2038 on 32 bit > >OSes. > > Well, what I meant was that you often have to deal with a lot of different > date-formats such as timestamps, short-date, long-date, datetime, time only > etc.. I never meant we should use integers or not, the internal > representation in the class should be as flexible as it could be. > The philosophy behind object-orienting is to provide a atomic > representation of both code and data. When you have to write different > functions for say adding a day to the date "2001-01-01" or the timestamp > "995395533" your're not very efficient. I think you are asking the wrong question to solve you problem. You are asking for something to handle with all possible date formats that you may find? I think the question should be, how to not have to handle with all those formats? > > > > I've used some date-classes I've done myself, but it is clear that all > > > would benefit from a standardized way of handling dates. And I think if > > > would fit perfectly into what PEAR is about if we could provide a solid > > > date-class. > > > Now, I know that there's already a Date_Date class, but that consists > > > solely of static functions and cannot be used to provide atomic > > date-objects. > > > Furthermore, this is something that's already been tackled by all major > > > object-capable languages. So there's no need to reinvent the wheel. > > > So I ask all of you, given experiences from other languages, what interface > > > and functions would you wan't to see in a common date-object? > > > > > >I don't know what you are looking for, but maybe you want to look into > >this class that eases the manipulation of dates in forms, by generated > >locale sensitive input fields for forms setting and retrieving date time > >values. > > > >http://phpclasses.UpperDesign.com/browse.html/package/230 > > Nah, not really what I meant. > I meant a class with an internal representation of a date which is mappable > to different external representations of that date. > $date->toDateTime() > $date->toTimestamp() > $date->toShortDate() > $date->toLongDate() > etc. > > And if you wanted to compare a date entered by a user with a date in a > database in the format of a timestamp you could do: > $date1 = & Date::FromISO($entry); > $date2 = & Date::FromTimestamp($timestamp); > $res = $date1->compareTo($date2); > if ($res === DATE_EQUAL) { > echo "Equal!"; > } elseif ($res === DATE_LESS) { > echo "Less!"; > } else { > echo "More!"; > } > > Or if the database stores it as a datetime: > $date2 = & Date::FromDatetime($datetime); > > And if you want to display the value in the database (be it timestamp or > datetime or anything else) you only have to do: > $date2->asLongDate(); > > etc. If you're problem is handling the different date formats that databases take, may be you would like to try Metabase which is a PHP database abstraction package that is focused on database portability, so you don't have to handle database differences in your applications. That way you can write database independent applications. Among many other things Metabase is able to convert data that goes back and forth the database. It abstracts date and time formats so that the application only has to handle them in the ISO 8601 format. Almost all databases support that format natively, even if you need some to configure them explicitly, but Metabase handles that too. Any format conversions that may be needed are handled internally by each Metabase driver class. With such level of abstraction embedded in the database layer package, it becomes viable to develop other components based on Metabase like the one above, that do not have to handle with database differences when handling date data types or other things. Metabase is available for free here: http://phpclasses.UpperDesign.com/browse.html/package/20 > Locales could be made through subclassing, ie. > > class SweDate extends Date { > .. > } > > $date1 = & Date::FromISO('2001-01-01 01:01:01'); > $date2 = & SweDate::FromISO('2001-01-01 01:01:01'); > echo $date1->asTextualDay(); > echo $date2->asTextualDay(); > > would be: > Monday > Måndag > > Does anyone see the benefits? The class above handles localization issues and you don have to subclass it. Manuel Lemos