> - I didn't say we shouldn't port DateTime. My point was simply that, > based on the amount of date-related code on CPAN, this is an issue > that many people care about quite a bit. We would probably be well > served to consider it carefully and decide on what semantics we > really want. Maybe DateTime is exactly what everyone wants and all > we need to do is port it. On the other hand, there is something to > be said for Nathan's approach; isn't it worth discussing?
What I'm trying to get at isn't that DateTime's API should be preserved. I'm saying that the concept of DateTime should be ported. Core or not core - it doesn't matter. When use'd (or installed), it should override now() (and anyone else we can think of) to return an object that DWIMs, plus provides the interface you've outlined below. > Perhaps something like the typed operations that were discussed > recently: > > my ($launch_date = now() + 6 weeks) but time(9am); > say "We will launch on a $lauch_date.day_of_week, at > $launch_date.time_of_day."; > say "This gives us " . $launch_date but hours . " hours, > including weekends and evenings."; Sure. $launch_date is of type DateTime. It will numify to the seconds-since-the-epoch, stringify to some date string, and provide all the neat-o-keen methods you want it to have. Frankly, I think we're in violent agreement here. I don't think this is something that needs to be built into the language. This is something that should be strongly-recommended for downloading. Kinda like you always expect DBI to be around when you go to a new major client, but it's not core. Well, I always expect DBI to be around ... :-) Rob
