RE: Formatting dates for locales/time zones
On 3/21/06 Garrett, Philip (MAN-Corporate) wrote: >> > So is cloning really the only way to do this? >>Dave Rolsky answered: >> I'm afraid so. But that's what the clone api is for. I'm not sure >> why you're averse to it, it's actually implemented in a way that >> should be quite fast. > >My aversion is more philosophical than practical. I'm working on >internationalizing some software right now, and (of course) one of the >main goals is to decouple presentation from data. I chose DateTime for >my date needs only to later find that the presentation (locale/output >time zone) for this core support module is embedded in its data. It's >the very thing I've been struggling against for months. > >I'm actually quite surprised that *you* don't see this as a problem. I'd suggest that with dates and times location is part of the data. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Is it ok to use "zero-but-true"?
On 2005-01-20 [EMAIL PROTECTED] wrote: >DT::Set count() currently returns "undef" on error, and "0" for empty >sets. >Should it return "zero-but-true" (0e0) for empty sets? I use 0e0 (or '0 but true') in lots of cases where an empty set is a valid return value, where zero is a valid index, and where zero is a valid input datum not the same as that datum being "empty", all cases where truth tests alone aren't sufficient to distinguish a real zero from '', undef, etc. But I've wondered: is zbt one of those charming Perlisms that, for all its utility, might fall by the wayside or be shown to harbor potential for serious errors? >Such that you could write: > $count = $set->count or die "can't count"; >instead of: > $count = $set->count; die "can't count" unless defined $count; I say this is an improvement, pending enlightenment on the above question. As always, Flavio, thanks for your good work. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Problems with (and patch for) February 30th in t/006_locales.t in DateTime::Format::Strptime 1.06
On 8/31/04 Dave Rolsky wrote: >On Tue, 31 Aug 2004, Rick Measham wrote: >> At 9:33 am -0700 2004-08-30, Jonathan Leffler wrote: >> >It looks like the test is trying to use February 30th. My >> >impression is that the problem is in the test, not the module being >> >tested. >> Dave, this looks more like an error in DateTime ... shouldn't >> setting the month work like adding a month and have it roll over ... >> or better shouldn't it truncate it to the month length? >> is that the error shouldn't occur. >I think throwing an error is the best thing here. It's really hard >for me to do something "reasonable" (as in obvious to most people) >when you try to convert the date to Feb 30. You came up with two >reasonable suggestions all by yourself ;) > >And really, I think that this code is indicative of a logical error in >the caller's code, or bad user input being passed through, and >throwing an error makes it obvious this happened. Truncating or >rolling-over will simply mask the error, which will translate into >corrupt data somewhere down the line. Pace that, the list had extensive discussion early on about specifying end-of-month handling when doing date calcs. Hence the 'wrap', 'limit', and 'preserve' modes for the end_of_month parameter in DT::Duration. Absent such a parameter, no date calculation would be correct in the usual meaning of 'correct'. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: "localtime" DateTime Objects
On 7/2/04 Rick Measham wrote: >DateTime->now() returns a UTC time unless given a time zone. >On the other hand, DateTime->new() returns the local time zone unless >otherwise instructed. > >Dave, can you enlighten me as to why this is the case? Shouldn't all >constructors that don't have a time_zone attribute assume the same? >(Which I'd prefer to be local if we can get it) Some of us need non-localized times; i.e., "floating". UTC as default is a Good Thing in some scientific contexts, for example. And for multi-location calcs, localization should be the last thing to be applied, not the first. But why DT->new() and DT->now() don't return the same thing, whichever it is, I don't recall. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: DT::Duration overloads
On 6/11/04 Rick Measham wrote: >I said: >>On the other hand, maybe these should be DateTime::Set methods: >> my $mean = $set->mean( $sunrise, $sunset ); my $median = >> $set->median( $sunrise, $sunset ); > >On Thu, 10 Jun 2004 18:04:36 -0700, Bruce Van Allen wrote >> Huh? I'm confused by your usage of 'mean' and 'median'. In the case >> in question, I think 'midpoint' is a much clearer term to use. > >I suggest placing mean and median in a module rather than just the FAQ >because the current solution is just the midpoint of two datetimes. >The mean can give this, but can also give results for more than two >datetimes. This doesn't change my mind that 'midpoint' is way better for what the OP was asking than mean or median. >As for my usage of 'mean' and 'median': >'mean' and 'median' are mathematical constructs. The 'mean' is often >called the 'average' while the 'median' would be the middle value. Thanks. I didn't need the math lesson -- I was asking about _your_ usage of mean & median :-) Your earlier post had the following: > use DateTime::Util::Stats qw/:all/; > # Solar Noon is the mean of sunrise and sunset: > my $mean = mean_datetime( @dt_list ) > # The mean is: round(scalar(@_) + 1 / 2) # IIRC > # therefore $median == $sunset > my $median = median_datetime( @dt_list ) I think it's slightly obfuscatory to tell someone to calculate a date/time midpoint using ideas of averaging. It's just a different goal. Also, as Matt Sisk said: >Midpoints are compelling, but also arbitrary. I'd like to see the >general problem of portioning a span, or the delta between two >arbitrary datetimes (expressed as a span or otherwise, transparently), >solved in a general way... This idea seems more relevant to the OP's question, and also more useful than using mean or median. "# therefore $median == $sunset" demonstrates my point that this is a mis-application of median. That outcome is an artifact of your algorithm for median -- what practical use would it have? My further concern, expressed several months ago, is that having a catch-all module like DateTime::Utils just begs for code creep. What Flavio posted could not be much more succinct: >Matt Sisk wrote: >> what is the midpoint of a span? And [EMAIL PROTECTED] wrote: >With DateTime::Span: > > $mid_point = >$span->start->add_duration( >seconds => $span->duration->seconds / 2 >); > >With DateTime: > > $mid_point = >$start->add_duration( >seconds => $end->subtract_datetime_absolute( >$start >)->seconds / 2 >); Best, - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Re: DT::Duration overloads
On 6/11/04 Rick Measham wrote: >On Thu, 10 Jun 2004 [EMAIL PROTECTED] wrote: >> How about a DateTime::Span->midpoint method? > >On 11 Jun 2004, at 6:55 AM, Dave Rolsky replied: >> Let's wait and see if others ask for it. For now, let's just >>add those recipes to the faq. > >I'm not sure of the best namespace, but I can see a Util namespace >would be a good place for FRSs (Frequently Required Solutions) Flavio's solutions are brief and efficient. Why not just have it in the FAQ, as Dave suggests? > use DateTime::Util::Stats qw/:all/; > # Solar Noon is the mean of sunrise and sunset: > my $mean = mean_datetime( @dt_list ) > # The mean is: round(scalar(@_) + 1 / 2) # IIRC > # therefore $median == $sunset > my $median = median_datetime( @dt_list ) > >On the other hand, maybe these should be DateTime::Set methods: > my $mean = $set->mean( $sunrise, $sunset ); > my $median = $set->median( $sunrise, $sunset ); Huh? I'm confused by your usage of 'mean' and 'median'. In the case in question, I think 'midpoint' is a much clearer term to use. My $.02. 1; - Bruce __bruce__van_allen__santa_cruz__ca__
Re: RFC: API for DateTime::Business:Week (was Re: Time Delta)
On 2003-10-03 Dave Rolsky wrote:
>I see us needing a couple things: - Recording the fact that certain
>days are special non-work days. This includes both public holidays,
>company holidays, one shot things like "fumigating the building", etc.
> We not only want to record when these are, but their names
>("Christmas", "Company Founder's B-Day", "Fumigation Day", etc.) and
>possibly other arbitrary data associated >with them.
But this should really be kept to a minimum imo, perhaps just one
additional field for a key to look up the associated data somewhere
else. Individual days might collect several layers of special
information. And whatever approach is used, we need to be able to look
things up both ways, i.e., by the date and by the special datum. Otherwise Fumigation
Day could get scheduled for Founder's B-Day.
In some of my production calendars, each day has 30 or 40 pieces of
associated information, so I use date methods to derive the set of
dates, then create a table -- in memory or database -- with the dates
as primary keys. When the layout program calls for a date, it gets an
object with all that date's info plus self-awareness of its place in
the set. From this perspective, I wouldn't need DateTime::Business to do much besides
provide the sets or spans, plus the math.
I suppose DT::Biz could provide an API for populating the individual date objects,
which would then inherit DT::Biz math etc methods; maybe this is what you meant. My
caution is just to keep in mind that the associated data can multiply, and a structure
that incorporates the associated data for a whole set of dates/times could get large.
Dave also said in response to some advance thinking by Rick:
>The first thing we need is a "business calendar" module that lets us
>define standard work days/hours, days off, and partial days.
>
>It should also be able to do calculations like, tell us how many
>business days occur between two dates, how many business hours/minutes
>occur between two datetimes, and generally let us do "business
>datetime math".
>
>Then we can use that module in another module that implements the
>per-employee stuff you're interested in.
Dave++
And Flavio said in anther message:
>How about trying to figure out a rough DateTime::Business::* directory
>structure? It would also help other authors to find out where to put
>their modules.
Flavio++
- Bruce
__bruce__van_allen__santa_cruz__ca__
RE: figuring out the number of sundays in a given year
On 9/20/03 Joshua Hoblitt wrote: >> I'm not sure about the count in a year, but I frequently need to >> determine how many of a given day of the week fall in a given month >> of the year, or, more precisely, given that today is Saturday, >> September 20, I need to figure out whether today is the first, >> second, third, fourth, or fifth Saturday of the month. I've worked >> out code using existing methods to tell me what I need to know, and >> I'm not sure that an entirely new method is warranted here. > >To generalize: > >You want to know how many of a given day occur in a range and at what >position in that range a given datetime is? > >This sounds like something that should operate on a DT::Span object. > It's a recurrence set. ->count is how many, index in set array (+1) is position. - Bruce __bruce__van_allen__santa_cruz__ca__
UTC FAQ for DT v.5
Hi All: Fourth revision. Thanks again to Eugene. Ben, note the é (é) in Coordonné. ## FAQ entry: Q. Does DateTime handle leap seconds? A. Yes Q. What is a leap second, anyway? A. One rotation of the Earth (1 day) is not exactly equal to 86,400 (i.e., 24*60*60) seconds. This means that an extra second, numbered 23:59:60, has to be inserted at the end of a day once every few years. This is similar to the system of leap days (February 29), which account for the difference between 1 year and 365 days. Many computer programs don't cope with leap seconds correctly; DateTime does! See "What time scale does DateTime follow?" for more about this. Q. What time scale does DateTime follow? What's up with UTC, GMT, TAI, and UT1? A. The DateTime modules are based on a time scale known as UTC (Temps Universel Coordonné, Coordinated Universal Time), which was established internationally in 1972. UTC is widely used in scientific and technical contexts, and has been accepted as the standard time scale for most uses. Civil time generally differs by an integral number of hours from UTC, expressed as time zones. Related time scales include: - GMT (Greenwich Mean Time), which was historically based on civil time in London (the "imperial clock"); for time calculations on dates after the introduction of UTC, GMT is equal to UTC; - UT1 (Universal Time), in which day length varies, and is slowly changing, due to irregularities in the earth's rotation detected by astronomical observations (the "earth clock"); - TAI (Temps Atomique International), in which a day has 86,400 seconds whose length is derived from a chosen atomic resonance at sea level (the "atomic clock"). UTC was developed to combine the stable atomic precision of TAI with the earth-sun accuracy of UT1. TAI was originally synchronized with UT1 on 1958 January 1 (i.e., on that date, UT1 - TAI = 0). Because of the slowing down of the rotation of the earth, the TAI - UT1 difference has grown irregularly since 1958. To reconcile the divergence between TAI and UT1, UTC is defined to differ from TAI by integer atomic seconds and to differ from UT1 by less than .9 atomic seconds. To maintain this relationship, leap seconds are introduced as needed to the UTC time scale, under the supervision of the International Earth Rotation and Reference Systems Service (http://www.iers.org/iers";>IERS). As an example, in May 2003, TAI - UT1 was measured to be 32.4 seconds, and TAI - UTC had been incremented to 32 seconds by the IERS. When TAI - UT1 grows to 32.9 seconds, a leap second will be introduced. In the event that TAI - UT1 shrinks below 31.9 -- irregular Earth! -- the introduced leap second would be negative. The DateTime modules account for UTC leap seconds, providing full conformance with UTC. NOTE: In 2003, there was discussion about UTC's future use of leap seconds. In the event of a change in the UTC definition, the most likely outcome is that the DateTime modules will continue to follow UTC or its successor, and any leap seconds already introduced will be preserved. ## End of FAQ entry # - Bruce __bruce__van_allen__santa_cruz__ca__
UTC FAQ for DT v.4
Hi All: Third revision. Thanks to Flavio and Eugene. ## FAQ entry: What time scale does DateTime follow? What's up with UTC, GMT, TAI, and UT1? The DateTime modules are based on a time scale known as UTC (Temps Universel Coordonne, Coordinated Universal Time), which was established internationally in 1972. UTC is widely used in scientific and technical contexts, and has been accepted as the standard time scale for most uses. Civil time generally differs by an integral number of hours from UTC, expressed in time zones. Related time scales include: - GMT (Greenwich Mean Time), in which each twenty-four hour day was exactly 86,400 uniform seconds; GMT was historically based on civil time in London (the "imperial clock"); for time calculations on dates after the introduction of UTC, GMT is equal to UTC; - UT1 (Universal Time), in which day length varies, and is slowly changing, due to irregularities in the earth's rotation detected by astronomical observations (the "earth clock"); - TAI (Temps Atomique International), in which a day has 86,400 seconds whose length is derived from a chosen atomic resonance at sea level (the "atomic clock"). UTC was developed to combine the stable atomic precision of TAI with the earth-sun accuracy of UT1. TAI was originally synchronized with UT1 on 1958 January 1 (i.e., on that date, UT1 - TAI = 0). Because of the slowing down of the rotation of the earth, the TAI - UT1 difference has grown irregularly since 1958. To reconcile the divergence since then between TAI and UT1, UTC is defined to differ from TAI by integer atomic seconds and to differ from UT1 by less than .9 atomic seconds. To maintain this relationship, leap seconds are introduced as needed to the UTC time scale, under the supervision of the International Earth Rotation and Reference Systems Service (http://www.iers.org/iers";>IERS). As an example, in May 2003, TAI - UT1 was measured to be 32.4 seconds, and TAI - UTC had been incremented to 32 seconds by the IERS. When TAI - UT1 grows to 32.9 seconds, a leap second will be introduced. In the event that TAI - UT1 shrinks -- irregular Earth! -- the introduced leap second would be negative. The DateTime modules account for UTC leap seconds, providing full conformance with UTC. NOTE: As of 2003, there was discussion about UTC's future use of leap seconds. In the event of a change in the UTC definition, the most likely outcome is that the DateTime modules will continue to follow UTC or its successor, and any leap seconds already introduced will be preserved. ## End of FAQ entry # - Bruce __bruce__van_allen__santa_cruz__ca__
Re: UTC FAQ for DT
On Thursday, July 17, 2003 Eugene van der Pijll wrote: >Bruce Van Allen schreef: >> Some may have seen the news that debate has flared up regarding the >> continued use of leap seconds. I don't know whether it will be >> resolved soon, so it seemed best to simply acknowledge the issue, and >> hope we remember to update the FAQ if something radically changes. > >This was based on a slashdot story; nevertheless it was a serious >proposal. There was a scientific meeting on the subject in Turin in May, >summarized at >http://www.mail-archive.com/[EMAIL PROTECTED]/msg00163.html (on >the LEAPSECS mailing list!). > >The options that were mentioned were: [snip] Thanks for the link. From that I gather that the issue wasn't resolved, that there is not necessarily an emerging consensus, amd that proposals for change regarding leap seconds would not be implemented for many years. I think this all means that the note about leap seconds in my draft FAQ is the best that may be said now from the DateTime standpoint. Eugene, propose something else for the FAQ if you'd like. >> This FAQ entry gets longer every revision, but it seems important for >> acceptance of DT that we have a fairly rigorous explanation. > >I doubt it. Not many people will be interested in the precise details. >People who really need to know it (e.g. those to whom it would cost >$100,000,000 dollar if the time is out by just one second) won't be >convinced by a simple FAQ entry. (I wouldn't be, at those prices.) Well, perhaps you aren't thinking about numerous Perl programmers who work in scientific/technical fields, who have to choose some time/date module to use, and for whom DT's basis in UTC would be reassuring... >My comments below are based on my web research of a few weeks ago. I >could be wrong, but I would like to know where you got some of your >info. >From from the IERS and YOUR posts, mostly ;) I have a few responses below to your comments. In a separate message I'll post another draft, incorporating some of your suggestions. > >> ## FAQ entry: >> >> UTC is widely used in scientific and technical contexts, and is >> increasingly accepted as the standard time scale for civic and >> business uses. > >"increasingly accepted"? Is there any business that is half a minute of >standard time? (Half an hour, yes. I commute by train.) >Better: "UTC (Temps Universel Coordonne, Universal Coordinated Time) is >the current standard time scale. Civil time (the time we all use in >day-to-day life) is based on UTC, and generally differs exactly an >integer number of hours from UTC, depending on your time zone." Following others' posts, I had backed off from asserting that UTC is the current standard time scale. > >> Related time scales include: >> - GMT (Greenwich Mean Time), in which each twenty-four hour day has >> exactly 86,400 uniform seconds by international convention (the >> "imperial clock"); > >AFAIK this is not true. What's not true about it? In the structure of the draft description, the main point was to establish the mathematical aspects of GMT, namely that "each twenty-four hour day has exactly 86,400 uniform seconds." Is this not the case? > >Better: "GMT (Greenwich Mean Time), the civil time in London (and by >extension, in the whole UK, and elsewhere) in winter. Since the >introduction of UTC, GMT is equal to UTC." See next FAQ version. > >> TAI was originally synchronized with UT1 on 1958 January 1 (i.e., on >> that date, UT1 - TAI = 0). To reconcile the divergence since then >> between TAI and UT1, UTC is defined to differ from TAI by integer >> atomic seconds and to differ from UT1 by less than .9 atomic seconds. > >> To maintain this relationship, leap seconds are introduced as needed >> to the UTC time scale, under the supervision of the International >> Earth Rotation and Reference Systems Service (> href="http://www.iers.org/iers";>IERS). > >Perhaps these paragraphs could be rewritten a bit clearer: > >TAI was originally synchronized with UT1 on 1958 January 1 (i.e., on >that date, TAI - UT1 = 0). Because of the slowing down of the rotation >of the earth, the TAI - UT1 difference has been growing since 1958. In >May 2003, TAI - UT1 was measured to be 32.4 seconds. > >UTC follows UT1 as accurately as possible, while keeping the difference >with TAI an integral number of seconds. At the time of writing, TAI - >UTC is 32 seconds. To maintain the relationship between UT1 and UTC, a >leap second will be introduced as soon as TAI - UT1 reaches 32.9 >seconds, as determined by the International Earth Rotation and Reference >Systems Service (http://www.iers.org/iers";>IERS). That's not a definition, although it has some better description than I wrote. See next version. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: UTC FAQ for DT
On Thursday, July 17, 2003 Flavio S. Glock wrote: >Bruce Van Allen wrote: >> UTC is widely used in scientific and technical contexts, >> and is increasingly accepted as the standard time scale for >> civic and business uses. > >s/civic/civil/ ? > >++ > >- Flavio S. Glock > Yes, s/civic/civil/ . Thanks. - Bruce __bruce__van_allen__santa_cruz__ca__
UTC FAQ for DT
Hi All: Here's a second revised FAQ covering DateTime's use of the UTC time scale. If this is OK (Dave and Flavio?), Ben, could you add it to the DT FAQ? Some may have seen the news that debate has flared up regarding the continued use of leap seconds. I don't know whether it will be resolved soon, so it seemed best to simply acknowledge the issue, and hope we remember to update the FAQ if something radically changes. This FAQ entry gets longer every revision, but it seems important for acceptance of DT that we have a fairly rigorous explanation. ## FAQ entry: What time scale does DateTime follow? What's up with UTC, GMT, TAI, and UT1? The DateTime modules are based on a time scale known as UTC (Coordinated Universal Time), which was established internationally in 1972. UTC is widely used in scientific and technical contexts, and is increasingly accepted as the standard time scale for civic and business uses. Related time scales include: - GMT (Greenwich Mean Time), in which each twenty-four hour day has exactly 86,400 uniform seconds by international convention (the "imperial clock"); - UT1 (Universal Time), in which day length varies, and is slowly changing, due to irregularities in the earth's rotation detected by astronomical observations (the "earth clock"); - TAI (Temps Atomique International), in which a day has 86,400 seconds whose length is derived from a chosen atomic resonance at sea level (the "atomic clock"). UTC was developed to combine the stable atomic precision of TAI with the earth-sun accuracy of UT1. TAI was originally synchronized with UT1 on 1958 January 1 (i.e., on that date, UT1 - TAI = 0). To reconcile the divergence since then between TAI and UT1, UTC is defined to differ from TAI by integer atomic seconds and to differ from UT1 by less than .9 atomic seconds. To maintain this relationship, leap seconds are introduced as needed to the UTC time scale, under the supervision of the International Earth Rotation and Reference Systems Service (http://www.iers.org/iers";>IERS). The DateTime modules account for UTC leap seconds, providing full conformance with UTC. NOTE: As of 2003, there was discussion about UTC's future use of leap seconds. In the event of a change in the UTC definition, the most likely outcome is that the DateTime modules will continue to follow UTC, and any leap seconds already introduced will be preserved. ## End of FAQ entry # - Bruce __bruce__van_allen__santa_cruz__ca__
Re: DateTime parse(), parser()
On Monday, July 14, 2003 John Peacock wrote: >John Siracusa wrote: >> Great, but the $64K question is: do we then get parse() and parser() methods >> in DateTime, which default to use DT::F::Simple? :) >> >A while ago, when this discussion last reared its [ugly] head, I suggested that >the base class contain methods which would call an array of potentially more >expensive parsers, until one returned a value other than undef. The default >install would only include the smallest, fastest parser and the user could add >other to the list. > >Thinking about it now, it would make the most sense to me to make >DateTime::Format be an actual class which would dispatch to the DT::F::something >modules. That way, nothing needs to be added to the DateTime class itself, if >you never need parsing. Some good ideas are converging here. Couldn't the following all be possible: 1. DT::Format as an actual class, per John S; 2. DT::Format has parse() and parser() methods; 3. DT::Format dispatches to DT::F::XXX modules, using DT::F::Simple unless the user has called parser(). 4. DateTime also has methods parse() and parser(), per John P, which simply invoke DT::Format and hand off their params to DT::F's own parse() and parser() methods; 5. If the user doesn't call parse() or parser() from DT, then DT::F and DT::F::XXX are never invoked by DT; 6. All parsers fail (return undef) if they can't parse a string, both for good programming practice and to allow falling through to the next specified/available parser module; 7. parser() -- or parsers()? -- would let the user specify which of the available DT::F::XXX modules to use, and the order with which they are tried. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: DateTime::Duration nits...
On Tuesday, July 1, 2003 [EMAIL PROTECTED] wrote: >Why not: > >$dur1 = new DT::Dur( days => 2 ); >$dur2 = new DT::Dur( months => 1 ); >$dur3 = $dur1 - $dur2; >$dur3->add( days => 3 ); > >If you add $dur3 to a date, it would add 2 days and >subtract a month, then add 3 days again. > >This is not too difficult to implement. >Is it too confusing? So is $dur2 above an abstracted month? That is, it isn't really resolved into a specific number of days until applied to some real start date? Likewise, how many days long is $dur3 above? It would seem like it holds the real arithmetic in suspense until added to a specific date, yes? > >On Mon, Jun 30, 2003 at 12:20:43PM -0500, Dave Rolsky >wrote: >> > 2) Having a way to construct this directly would >be nice being able >> > to make a duration that you can not directly >construct seems odd. >> >> Well, maybe. Right now the constructor is really >simple, which is good. >> More functionality is nice, but so is simplicity. > - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Getting different results from DateTime and Manip for epoch time
On Tuesday, June 24, 2003 [EMAIL PROTECTED] wrote: >Bruce Van Allen wrote: >> How's this: >... >> Before UTC, other time scales were in use, >> including: > >Maybe: > "There are other time scales, such as:" > >because some are still in use (?) Good point. I was trying to convey something about the progression to UTC. UTC has been adopted for many uses in place of other time scales, including: - GMT ... Other time scales, now wholly or partially supplanted by UTC, include: - GMT ... - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Getting different results from DateTime and Manip for epoch time
On Sunday, June 22, 2003 [EMAIL PROTECTED] wrote: >I'll try to rephrase this, because it >would be good to have it in the FAQ. >If somebody can explain it better, or >more correctly, please help me! How's this: What time scale does DateTime follow? What's up with UTC, GMT, TAI, and UT1? The DateTime modules are based on a time scale known as UTC (Coordinated Universal Time), which was adopted internationally in 1972. Before UTC, other time scales were in use, including: - GMT (Greenwich Mean Time), in which each twenty-four hour day has exactly 86,400 uniform seconds by international convention; - UT1 (Universal Time), in which day length varies, and is slowly changing, due to irregularities in the earth's rotation detected by astronomical observations (the "earth clock"); - TAI (Temps Atomique International), in which a day has 86,400 seconds whose length is derived from a chosen atomic resonance at sea level (the "atomic clock"). TAI was originally synchronized with UT1 on 1958 January 1 (i.e., on that date, UT1 - TAI = 0). UTC was developed to combine the stable atomic precision of TAI with the earth-sun accuracy of UT1. UTC is defined to differ from TAI by integer seconds and to differ from UT1 by less than .9 seconds. To maintain this relationship, leap seconds are introduced as needed to the UTC time scale, under the supervision of the International Earth Rotation and Reference Systems Service (http://www.iers.org/iers/";>IERS). # - Bruce __bruce__van_allen__santa_cruz__ca__
Re: DT::Fiscal::Year
On Sunday, June 22, 2003 Jesse Shy wrote: >OK, I am coding up the port from Date::Calc::Fiscal right now. Yay. The DT project advances into a new continent of usefulness! >It will have only 2 methods right now, day_fiscal_year - if Mar 1 is >fiscal start, then Mar 1 is day 1 not 59; week_fiscal_year - if start >is Mar 1 then Mar 1 - 7 are week 1. This also means that if Mar 1 is on >Wed, then the fiscal weeks are from Wed to Tues, Feb 28 and 29th of the >previous >fiscal year are not in week 1 of this fiscal year even though >they are in the same >Mon - Sun segment. This is as it should be. Life just got easier for Accounting Dept programmers. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Standalone Times?
On Sunday, June 22, 2003 Eugene van der Pijll wrote: >Bruce Van Allen schreef: >> From a string in the form MM, the DT::F::ISO8601 parser >> should return a DT object identical to the DateTime object >> instantiated from >> $dt = DateTime->new( >> year => 2003, >> month => 6. >> ); > >No. > >Let me show you a couple of ISO8601 time intervals, and my >interpretation of them: > >Tomorrow, I have a meeting on "2003-06-22T15/17". I would expect this >meeting to start at 15:00:00, and to end at 17:00:00. That is, both >start and end times are rounded down. > >This year, the Tour de France is "2003-07-05/2003-07-27". Cyclist >shouldn't expect to go shopping in Paris on the 27th, as they will be >busy until late that day (besides, it's a Sunday and the shops will be >closed). The best interpretation of that end date is something like >2003-07-27T23:59:59 or 2003-07-28T00:00:00. That is, end date is rounded >up (and the start date is rounded down). > >Julius Ceasar lived "-0099/-0043". The starting date should here be >interpreted as "somewhere in 100BC, and the end date should be >interpreted as "the ides of March 44BC". Setting both to Jan 1st would >be simply wrong. Got it. I was seeing -MM only as a truncated date. Seems a challenge to devise rules for this. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Standalone Times?
On Sunday, June 22, 2003 Dave Rolsky wrote: >On Sat, 21 Jun 2003, Bruce Van Allen wrote: >> The point of DT::Format::XXX is parsing and formatting: >> - to return a DT object if given an XXX-formatted date/time string; >>and >> - to return an XXX-formatted string from a DT object. > >Well, the formats can also include formats for durations, recurrences, >etc. ISO has duration formats, and iCal has durations, periods (aka >spans), and recurrences. > Yes. I should have said "The BASIC point of DT::Format:XXX ..." The other formats are specific to the system to be parsed/formatted (MySQL, iCal, etc.). The context was a question that seemed to be veering away from the DT::F API, by not returning a DT object from parsing a string. (Unless I misunderstood.) - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Business Dates
On Saturday, June 21, 2003 Dave Rolsky wrote: >On Sat, 21 Jun 2003, Jesse Shy wrote: >> I would like to tackle number one below by porting what I have from >> Date::Calc; I am taking this as implicit permission to use the >> DT::Business::FiscalYear namespace for this OK? > >That seems like the best namespace to me. Anyone else have thoughts on >this? I'm not sure. Government, education, the nonprofit sector, and perhaps other realms utilize various fiscal years, so having ::FiscalYear under ::Business might not be optimal. One thought: A "fiscal year" is type of calendar, and as the (long-ago) DT consensus was that all "calendars" are adopted fictions, perhaps it should be DT::Calendar::FiscalYear. The API would have to be somewhat different from the existing DT::C modules, to accept the appropriate start-day and other parameters, rather than having these things written in as with the 'normal' Calendars. Maybe DateTime::Accounting::FiscalYear or even DateTime::Fiscal::FiscalYear as both "accounting" and "fiscal" are terms used beyond business.
Re: Business Dates
Hi All: [This was already written when Dave posted his latest comment: >While I know that DateTime::Business stuff will eventually probably get >really complicated, I think starting off with one simple implementation >just to get the ball rolling is a good idea. If people need something >different, they'll tell us, or even better, implement it themselves. so consider this as exegesis...] There's been quite a bit of talk about how to handle date and time for business & fiscal applications. I urge _not_ trying to create a comprehensive module. Instead, an extensible framework, within a DT::Business or DT::Fiscal namespace, could grow incrementally, under the discipline of avoiding the creeping redundancy starting to infect the DT project. I've been reviewing contracts, leases, nonprofit grant agreements, and similar business documents, for date and time elements that might be abstracted for programming. I got started on this after a DT discussion months ago about 30-day business months; I went looking for legal definitions, terms of trade, standard practices, etc. One of the most ubiquitous sentences showing up is "Time is of the essence of this agreement." Economic activity is utterly embedded in time; without a time dimension, any definition of value, work, money, wealth, or exchange is incomplete, and any calculation is wrong. I mention this to suggest that there would be too many things to handle in a unified code base. Kinda like if you wanted a map showing full detail, the map would have to be as extensive as the land it portrays. I think we could hurt ourselves trying to conceive, much less design and code, a comprehensive model. So, then, what? Let's expect work to proceed in parallel: a) identify usages over time; b) abstract specific usages into models based on DT building blocks; c) develop testable code for specific usages. Identifying usages could start with just a list of goals or questions. "I want to be able to set up an accounting calendar starting at an arbitrary date." Abstracting to the existing DT code base is the part that will save time and sanity. IMO, many of the issues wracking the DT list lately spring from not fully appreciating the power of the DT capabilities already available, hence the creeping redundancy mentioned above. Thanks to Dave, Flavio, and the other ace DT programmers, there is now a set of building blocks -- date calcs, durations, recurrence sets, spans and sets of spans, calendars, etc. -- from which most applications may be readily built, albeit with a little thought and discussion. No need to get into a spot of feeling overwhelmed by the desire for completeness in business time/date usages. Let's remember the phycists' joke that time is nature's way of keeping everything from happening at once. - Bruce __bruce__van_allen__santa_cruz__ca__
RE: ISO 8601 is eeeevil!
On Thursday, June 19, 2003 Jerry Wilcox wrote: >At 4:25 PM +0200 6/19/03, Peter J. Acklam wrote: >>Anyway, I see your point, but I don't agree. There is only need >>for an agreement when ambiguous formats are used, which is a good >>thing since ambiguous date formats are, as everyone here knows, a >>big pain in the butt. >> >>Those who wrote the standard could, of course, have disallowed all >>formats which are ambiguous, but these formats are sometimes >>useful, so they allowed them on the condition that everone agrees >>on what the ambiguous formats are supposed to mean. >> > >I have to say that I agree with Peter here. A "standard" set of >library modules cannot, by definition, support whatever outside >agreements might be in place between two organizations. Any module >that purports to be generally useful should simply disallow ambiguity >by never assuming that a format is an expanded (per the ISO >definition) one. > >Jerry I concur. An interesting challenge here might be to devise a way to allow DateTime to exploit the full range of ISO 8601 formats, in cases where the user knows that the appropriate agreements exist among the parties. Perhaps a DT::F::ISO8601 parameter like accept => ['DDD'], could be used, evoking the necessary routines to parse & format. (I put this in the form of an array ref to handle multiple accepts.) Just a thought. - Bruce
Re: [announce] DateTime::TimeZone::Alias 0.01 (fwd)
Perhaps I'm not following closely enough, but this thread is confusing
me.
On Tuesday, June 17, 2003, at 02:51 PM, Ben Bennett wrote:
On Tue, Jun 17, 2003 at 09:52:46AM -1000, Joshua Hoblitt wrote:
How would an add method that returns silently if an alias is already
defined tell if an alias has been redefined somewhere else?
It _only_ returns silently if the current definition matches the
real timezone of the requested definition:
--
my $dta = "DateTime::TimeZone::Alias";
$dta->remove("EST");# Start with a clean slate
Clean from what? Is EST already in there? How and why?
$dta->add("EST" => "US/Eastern"); # Succeeds
$dta->add("EST" => "US/Eastern"); # Succeeds
$dta->add("EST" => "America/New_York"); # Succeeds
How is it known that "US/Eastern" "matches the real timezone of the
requested definition", "America/New_York"? Is "US/Eastern" also a valid
TZ name, like "America/New_York"? Since it's the ALIAS that usually
gets bandied about, why would one be changing an alias definition from
"US/Eastern" to "America/New_York" if they really stand for the the
same underlying time zone?
$dta->add("EST" => "America/Chicago"); # Fails
Is this failing because the string "America/Chicago" is different from
the string "America/New_York"? Rather, I hope it's because DT::TZ::A
looks up each proposed definition...
I'd be wary of any aliasing system that knows what's best.
What if my program allows a continuous NOW time zone for fast-traveling
users, who only need to know or record time as 2003-06-17T16:20:00 NOW.
The program re-sets the NOW alias at each airport, or by checking
global position, or star light, or ..., so the traveler always
functions in local time and her logs are always correct with respect to
home or UTC. As I understand this thread, I couldn't redefine an alias
once it's (correctly) defined, right? Why use add() and remove()
instead of set()?
- Bruce
__bruce__van_allen__santa_cruz__ca__
Re: Nanoseconds in the FAQ.
On Wednesday, June 11, 2003, at 07:08 PM, Ben Bennett wrote: I added a section on nanoseconds: The raw POD is below. =head3 How small an increment of time can I represent? A can represent nanoseconds. You can create obects with =for example begin # The ns part is 0.00230 below my $dt_ns = DateTime->new(year => 2003, month => 3, day => 1, hour => 6,minute => 55, second => 23, nanosecond => 230); print "ns: ", $dt_ns->nanosecond, "\n"; # Prints: "ns: 230\n" # Assuming we got microseconds as an argument ^ I think you meant:milli my $ms = 42; my $dt_ms = DateTime->new(year => 2003, month => 3, day => 1, hour => 6,minute => 55, second => 23, nanosecond => $ms * 1_000_000); print "ms: ", $dt_ms->nanosecond, "\n"; # Prints: "ms: 4200\n" ^^ That number is in nanoseconds (42 milliseconds is 42,000,000 nanoseconds); does it make sense to label it 'ms' in the test output? - Bruce __bruce__van_allen__santa_cruz__ca__
Re: What should a business module implement?
On Thursday, June 5, 2003, at 04:39 PM, [EMAIL PROTECTED] wrote: Bruce Van Allen wrote: 1. This is one reason some us have argued for the capability of caching recurrence sets (which Flavio implemented!). I'm not done yet - but I've got it started. Sorry, what I meant was -- "Flavio has agreed to implement!" (and has a method to extend the set if necessary). Converting bit-arrays to/from DT::Set is easy. Cool. 2. Another aspect of business calendars concerns contract and billing periods, 3. A related area is work-time rules, I'm convinced that ICal is good enough for handling this kind of data descriptions: there are sources of ICal data in the internet, and we already have a parser (DT::Format::ICal). - Flavio S. Glock Good thought. Later this month I plan to build a new calendar system, so I'll try this out. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: What should a business module implement?
On Thursday, June 5, 2003, at 01:38 PM, Ben Bennett wrote: Very interesting post. On Thu, Jun 05, 2003 at 01:32:14PM -0700, Brad Hughes wrote: Ben Bennett wrote: Okay so what should a business date module be able to do? What is a "business day?" A quick glance at our internal date modules reveals over 40 different "business day" calendars. You've got, for example, the NYSE, NASDAQ, [snip] 1. This is one reason some us have argued for the capability of caching recurrence sets (which Flavio implemented!). Brad suggests another way to accomplish this, which would have application in some uses: In any case, my suggestion is, for each calendar, take a scalar where 1) each bit represents a calendar day, starting from some start date (data is available for the NYSE going back to 1885, when the NYSE had a special closing for the funeral of Ulysses S. Grant); 2) a bit is 1 if that day is a valid day for that calendar; 3) the scalar is uuencoded and stuck in a __DATA__ section. For functional calendars dedicated to specific uses, 3) is similar to what I've done, with my main module building a new module that drops any claim to universality, and stores its set of dates and their specialized attributes under __DATA__ (and has a method to extend the set if necessary). 2. Another aspect of business calendars concerns contract and billing periods, giving rise to 30-day months, discount schedules, and the like, many of which involve date-related terms of trade. A while ago I thought I'd get time to go through a bunch of documents and make a list of such commonly used items, but work grabbed all my tuits. 3. A related area is work-time rules, covering pay periods, breaks, overtime, comp time, accrual of benefits, etc. These are implemented within firms and industries, so would benefit from tools allowing pre-construction of DT sets according to rule sets. Any HR or Accounting Dept programmers out there? - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Rough first draft of a FAQ
On Thursday, May 29, 2003, at 09:39 PM, Rick Measham wrote:
Looking through the FAQ (thanks Ben!), the question about comparisons
is
raised. Clearly DT->now is only == to DT->today for one nanosecond.
Maybe we should add a routine such as the following to the core?
sub same {
$_[0]->clone->truncate(to=>$_[1]) ==
$_[2]->clone->truncate(to=>$_[0]);
}
I think you meant:
$_[0]->clone->truncate(to=>$_[1]) ==
$_[2]->clone->truncate(to=>$_[1])
^
this lets us say things like:
if (same($dt1,'day',$dt2)) { ... }
Eew.
Or, if you want to use it as an object method:
if ($dt1->same('day',$dt2)) { ... }
- What about testing more than two DT objects at a time?
- What is "same"? Basing it on truncate wouldn't allow testing for
things like the same hour on different dates.
- I'm not opposed to something like a DT::Utilities module, as your
next post mentions, but this could become a catch-all for a bunch of
hacks that add cruft or that veer off the DT API when the powers of DT
are sufficient.
- Isn't this pretty useful as is?
if ($dt1->day == $dt2->day) { ... }
if ($dt1->day_of_week == $dt2->day_of_week) { ... }
Maybe there are some other examples that show how same() would be
usefully implemented?
Also, thanks, Ben!
- Bruce
__bruce__van_allen__santa_cruz__ca__
Re: date math and local times
On Wednesday, March 12, 2003, at 01:02 PM, Dave Rolsky wrote: On Tue, 11 Mar 2003, Bruce Van Allen wrote: Upon catching that exception, I think I would always do a "carryover" operation, so the result in both cases would be 2003-04-06T03:00:00 w/ DST flag set. Are you saying you'd do the carryover yourself, or you expect DateTime.pm to do it? I'm saying it will have to be done, so I'd do it if DT doesn't. See below. The rule for the end of DST, as you mentioned, "First" wins, where first is defined as "earliest UTC datetime". has withstood every test I've thrown at it. I guess you're assuming that 03:00:00 wouldn't *always* be the expected result (at local start of DST)? No, this had to do with the switch from saving to standard, where here in the US 1:59 AM (saving) is followed by 1:00 AM (standard). So the question was what should be done if the user asks for "1:30 AM" on the day the switch occurs, and my answer was that the earliest UTC time wins, which always means saving time, not standard. But this doesn't cause any exceptions, of course. The exceptions are caused when the user does something that tries to produce a wall clock time that doesn't exist, which can happen at the transition from standard to saving. You misunderstood me. In my paragraph starting "I guess you're assuming that 03:00..." I'm referring back to April, the *start* of DST. Sorry I didn't make that more clear. I like the way the end of DST is handled, but I don't like the way the start of DST is handled, because I'll have to cover for the exception (unless DT does ;-). My question is really: is there an imaginable case where, on the start date of DST, the math shouldn't be 01:59:59 + 1 sec = 03:00:00 ?? If someone can demonstrate such a case, then DT should throw an exception; otherwise why not have DT do the "carryover"? - Bruce __bruce__van_allen__santa_cruz__ca__
Re: DateTime bug & default timezone
On Monday, March 10, 2003, at 07:10 PM, Dave Rolsky wrote: On Sat, 1 Mar 2003, Bruce Van Allen wrote: I agree with these thoughts and principles, but thinking of months as discrete units also has complications, as you say, with "weird unpredictable results": [snip] That's why there is an "eom_mode" (end of month mode) parameter for the DateTime::Duration constructor, which allows you to control how adding months is handled. Excellent. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: date math and local times
On Monday, March 10, 2003, at 04:26 PM, Dave Rolsky wrote: my $dt = DateTime->new( year => 2003, month => 4, day => 5, hour => 2, time_zone => 'America/Chicago', $dt->add( days => 1 ); then the code will throw an exception, because there is no local 2:00 AM on 2003-04-06 in the America/Chicago time zone. Is that acceptable? I can't think of any good solutions to this, other than documenting it. This is the same situation as: my $dt = DateTime->new( year => 2003, month => 4, day => 6, hour => 1, minute => 59, seconds => 59, time_zone => 'America/Chicago'); $dt->add( seconds => 1 ) Upon catching that exception, I think I would always do a "carryover" operation, so the result in both cases would be 2003-04-06T03:00:00 w/ DST flag set. So to protect my processes that scan across arbitrary periods at arbitrary levels of resolution (truncation), I will always have to be vigilant for an exception thrown by seemingly innocent math. Kinda like encountering (mathematically) imaginary numbers when balancing my checkbook... ;-) The rule for the end of DST, as you mentioned, >"First" wins, where first is defined as "earliest UTC datetime". has withstood every test I've thrown at it. I guess you're assuming that 03:00:00 wouldn't *always* be the expected result (at local start of DST)? - Bruce __bruce__van_allen__santa_cruz__ca__
Re: DateTime bug & default timezone
On Saturday, March 1, 2003, at 07:21 AM, [EMAIL PROTECTED] wrote: I'd say that the same applies .. add one month: 01:00 26 January 2003 + 1 month = 01:00 26 February 2003 01:00 26 February 2003 + 2 months = 01:00 26 April 2003 On Friday, February 28, 2003, at 10:56 PM, Dave Rolsky wrote: Hmm, I'm sure there are cases where people want the other implementation, though. I think that arises from fuzzy thinking. Lots of people assume that date units are reducable to seconds (I think influenced by years of working with epoch seconds), but reducing discrete units like months, weeks, and days to their time components is always going to produce weird unpredictable results. If they want to add the equivalent of 30 days in seconds vs. 1 month let them do that, we could even provide some constants like SECS_IN_DAY to make it easier. I think like the earlier rule of thumb about dates start at 1, times start at 0, it would be good rule of thumb that when adding date components the time stays the same. I agree with these thoughts and principles, but thinking of months as discrete units also has complications, as you say, with "weird unpredictable results": # per above examples: 01:00 31 December 2002 + 2 months = 01:00 31 February 2003 # NO # 'End of Unit' date [0]: 01:00 31 December 2002 + 2 months = 01:00 28 February 2003 # carryover -- but by what logic?? day of month math: 31 - 28 = 3 01:00 31 December 2002 + 2 months = 01:00 03 March 2003 business month math: 31 December + 30 + 30 01:00 31 December 2002 + 2 months = 01:00 01 March 2003 This DOES connect back to time of day, for example because compounding the discrepancies above with a few calculations could cross the cusp between Standard Time and Daylight Savings time, or NOT, depending on the month-adding logic. Yes, the probability of that example is low, 'cause the time change isn't near the start of a month, just like the hour of the time change is at 02:00/01:00 rather than at midnight. But still. I'd accept one or more arbitrary unit-adding methods, but not at the expense of unpredictably leaking hours. [0] In composing calendar layouts for print and web, it's often necessary to know things like 'the end of the month', which determines how many days away something is, rather than the reverse. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Floating time zone => non-floating
On Sunday, February 2, 2003, at 02:42 PM, Dave Rolsky wrote: On Sun, 2 Feb 2003, Dave Rolsky wrote: If I have a datetime object with a floating time zone and then I set the time zone to some non-floating zone, I shouldn't change the local time, right? And how about non-floating => floating? Same thing, no adjustment, right? Yes and yes. And if someone wanted different, it would be easy to have methods like: $dt->unfloat_from_UTC( time_zone => 'America/Chicago' ); which takes the floating time as UTC and offsets to local time for the object's now-anchored time. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Changing time zones?
On Thursday, January 30, 2003, at 05:19 PM, Dave Rolsky wrote: What should happen when someone does this: my $dt = ...; $dt->set( time_zone => 'America/Denver' ); and the new time zone is different from the old? There's two ways to do this. One is to keep the UTC time the same, which ends up shifting the effective local time. The other would be to change the local time (in effect shifting the UTC time). Be Here Now: 2003-01-30 15:30:00 Chicago These operations argue for constant UTC, shifted local time: When this shipment reaches Denver in 6 hours, what time will it be there? Schedule a conference call for people in Chicago, Denver, and London Map the path of an eclipse across Europe for local viewing Record a transaction whose parties are in San Francisco and Budapest I can't think of any yet that argue for shifting UTC, but the trooth is out there... On Thursday, January 30, 2003, at 05:52 PM, John Peacock wrote: Store in UTC (always). John, is there a principle that could be stated, behind your 'NSHO'? This seems clear to me, but then I wonder if I'm trapped in some thought rigidity. Are we always moving with the object in relation to the world the object starts from? All of the above examples have some element of 'right now' in them; e.g., to know what time it will be in Denver when the shipment arrives there, get Denver's time 'right now' and add the shipping time. Fixed UTC, by the nature of the question. Always the case? I'll take it as a working rule, but it makes me very curious about possible counter-examples... Especially considering time zones, I'm now convinced that 'time' for us relies on more fictions than even 'money'! [0] Real time for the universe is seconds since the big bang; for a person, it's what the sundial says outside the front door and how tall the kids have grown. Everything else is layers of symbols, schemes and schedules. I guess I'm going on about this as a way of expressing appreciation for Dave and others who have risen to turn convoluted fiction into logic. - got time zone stuff working (see previous message which no one responded to. sniff) I'm in a different TZ ;-) [0] Although money relies on time... - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Set/Get methods
On Friday, January 24, 2003, at 03:14 PM, Dave Rolsky wrote:
On Fri, 24 Jan 2003, Bruce Van Allen wrote:
be updatable at all. It appeared to me that consensus formed to have
objects static, and updating would be done via cloning:
I wouldn't say there was consensus ;)
So many threads and sub-threads...
As I said previously, it's appealing from an _implementor's_
standpoint,
and very logical, but I'm not sure that it actually makes for an API.
Yes, I was definitely seeing it as reducing the burden on the class's
internals. But also for my applications, I'd prefer DateTime to be
sleek, strong, and fast, because I know I'll be building things around
it. Clever is less important at this level if it means lots more code.
At the moment, I'm leaning towards making the object mutable, either
via:
$dt->day(6);
_or_ by just having one mutator sub:
$dt->set( day => 6, hour => 7 );
In general I agree with Rich Bowen's argument for unified get/set
methods. But in the case of DateTime it just seems like trouble to
introduce this. As I suggest below, we probably wouldn't want some
attributes to be mutable, so why create the expectation? It would be
simpler to spell out rules for a separate set() method.
For one thing, would either approach deal with anything besides the
date/time atoms (year, month, day, hour, minutes, seconds)?
$dt->set( month_name => 'January' ); # seems innocent
$dt->month_name('January'); # ditto
But what happens when:
$dt = DateTime->new(year => 2003,
month => 1,
day => 24); # init OK
$dt->week_day(); # 5 (Friday, Monday=1) # get OK
# Let's go to Tuesday
$dt->week_day(2); # Now what date is it??? # aack!
Much less:
# I try to set a custom abbreviation...
$dt->set(week_day_abbr => 'F'); # ?? For this date? for all Fridays?
$dt->add( day + 7 ); # Do some math on the object
$dt->week_day_abbr(); # 'F' or 'Fri'??
Another point is that the date/time atoms as you've described them are
all numeric; if they were the only mutable attributes, this feature of
the API would not be anglo-centric.
Will arguments be accepted that resolve to forms different from how the
attribute is expressed?
$dt->year(); # 2003 Attribute's format is: CCYY
$dt->year( $dt2->year() + 3 ); # OK
$dt->year( '03' ); # ? ERR or 3 AD? (it's not 2003)
$dt->year( '0003' ); # OK?
$dt->year( 3 ); # OK?
So, if the objects are mutable, I'd prefer:
- the minimum set of mutabilities, probably date/time atoms only;
- any mutation ramifies throughout the object (might mean re- or
de-memoizing);
- a separate 'set' method;
- however done, arguments for 'set' mode must and may only resolve to
the exact form that 'get' returns:
$dt->set( year => $dt2->year() ); # OK
$dt->set( year => '463 BC' ); # ERR
Cheers,
- Bruce
__bruce__van_allen__santa_cruz__ca__
Re: Set/Get methods
On Friday, January 24, 2003, at 03:45 AM, Rich Bowen wrote: Someone who is watching the list more closely than I appear to be pointed out to me that some discussion had occurred about get/set attribute methods. I can't find that discussion, and don't feel like [snip] Now, if this matter never came up, and the whole episode was imagined, then ignore me and move on your way. But I just wanted to note that I'm opposed to having to call ->attrib_get and ->attrib_set as different methods. Some of the discussion was about whether or not DateTime objects should be updatable at all. It appeared to me that consensus formed to have objects static, and updating would be done via cloning: $dt = DateTime->new( year => 2001, month => 5, day => 22 ); $dt2 = $dt->clone( day => 24 ); or some such. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: How about DateTime::Usage? [was: Re: Tests failing]
On Monday, January 20, 2003, at 11:34 AM, Bruce Van Allen wrote: Wait: what about Usage? DateTime::Usage::MySQL DateTime::Usage::ICal DateTime::Usage::MySQL::BrailleIO DateTime::Usage::MyOWN::Weird_Usage Actually, what I meant on the last one was: DateTime::Usage::User::MyOWN::Weird_Usage with DateTime::Usage::User being a means of adding specialized parser/fomatter methods without having to import anything else when using DateTime. - Bruce __bruce__van_allen__santa_cruz__ca__
How about DateTime::Usage? [was: Re: Tests failing]
On Monday, January 20, 2003, at 05:58 AM, Nick Tonkin wrote: DateTime::Format was rejected for making it sound like you would use it to format a date. Dave R's first suggestion was for DateTime::Rendition (iirc -- might have been Presentation?) Dave's original proposal was DateTime::Representation::... # where ... is e.g., MySQL 'Representation' is still very close to the correct *concept*, but not perfect; also kinda long, although as others have said, you don't type it out often. We're dealing with types of representations of dates. It's almost 'patterns', except that within a given parser we may have multiple 'patterns' for matching, so that might be confusing: DateTime::Pattern:: # probably not A concept close to pattern is form. DateTime::Form DateTime::Of_Form Wait: what about Usage? DateTime::Usage::MySQL DateTime::Usage::ICal DateTime::Usage::MySQL::BrailleIO DateTime::Usage::MyOWN::Weird_Usage DateTime::Formats could be read as a verb but not as an infinitive nor an imperative, which are the formats :) that are used to inidcate verb-ness in modules, imo. How about DateTime::StringFormat ? DateTime::Rendition DateTime::Rendering DateTime::Articulation DateTime::Depiction DateTime::Interpretation or how about DateTime::Structure - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Parser Interface
On Thursday, January 16, 2003, at 11:10 AM, after considering many points, Dave Rolsky wrote: I'll probably just go with the very straightforward API of: make a parsing object tell it to parse string X and return a DateTime make a formatting object tell it to format a DateTime object in a specific format This isn't particularly clever, nor is it super-convenient. But all the clever and convenient suggestions seem to arouse more dislike from some people, so it's easier to agree on the tried and true. It might not be ideal for anyone, but at least people who look at the modules will not be turned off by an API they consider to abnormal ;) OTOH, this might make it easier to contend with multiple (human) languages. Parsing and formatting both have to be language-aware, right? Localization might not always be optimal: a date might have to parsed from one language and formatted for another... I think Dave concluded that DateTime's own methods will be restricted to a few date formats like ISO, etc., that are (mostly) universal across human languages. With parsing and formatting objects as described above, it seems like extensibility would be available for those that need it. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: The first day of the week is ...
On Tuesday, January 14, 2003, at 02:24 PM, Antonios Christofides wrote: Dave Rolsky wrote: >Monday! > >How exciting. I figured I might as well just pick something, and so I >picked Monday. There were a lot of excellent candidates, and Friday's >performance was excellent, but overall Monday best exemplified the >qualities that I look for in a week-starter. > (rofl) No objection, and no "buts". But :-) since the discussion is getting real fun with all those Romans, Mayas, Chinese, and so on, I think I'll go on. [snip of interesting info about Greek/Christian origins of English/European day names] Aren't you going to do the same? (I'm just asking.) Isn't "weekend" the week end? Don't you feel that a cycle begins on the first working day of the week? The bottom line: Surely people all over the world do begin their diet on Mondays? I come at the "first day of the week" issue somewhat differently: my applications produce the many bits of information needed for creating visual calendars, i.e., for print, HTML, and other visual formats for human use. So for a given date I have to calculate a start-of-week for the visual layout as well as the appropriate start-of-week based on work-week, sacred tradition, tide-chart (for many here in Santa Cruz the cultural definition of 'work week' depends on surf conditions...), etc. In the U.S., most printed calendar _layouts_ have weeks starting with Sunday. Sun Mon Tue Wed Thu Fri Sat Because I've done some calendars that _don't_ have the typical (U.S) Sun-Sat week layout, my calendar-generating module is agnostic with respect to start-of-week, although it defaults to Sun-Sat weeks for convenience. The main thing is that it has to know what day-of-week *number* to use when setting its layout-start-of-week *day*. That's why I don't need the day-of-week number to be a 0-based index -- that just assumes that I want the zero-indexed value for the first day. Dave has announced that Monday has day-of-week number 1. That's all I need to know. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Parsing/Formatting API
On Tuesday, January 14, 2003, at 01:36 PM, Stephen R. Wilcoxon wrote: On Tue 2003/01/14 16:14:51 EST, Matthew Simon Cavalletto <[EMAIL PROTECTED] writes: Representation is kind of long-winded, and I'm not sure it communicates the text-centric nature of the code in question, but I could live with it. Agreed (Representation is longer than I'd prefer). Here are a few other candidate namespace options -- do any stand out? DateTime::Format::MySQL->parse( ... ) DateTime::Representation::MySQL->parse( ... ) DateTime::String::MySQL->parse( ... ) DateTime::Text::MySQL->parse( ... ) I don't like String or Text as it is possible that there could be a format that is not text. Of the four, I prefer Format (although I can see Dave's point about some people getting confused). Form, Formats, Idiom, Type, Mode, Style, Trans, Translate, IO, ... Form is concise, works as noun & verb. Formats (w/ 's') doesn't have the problem Dave pointed to for Format. IO? - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Base object API/semantics
On Friday, January 10, 2003, at 09:52 PM, Dave Rolsky wrote:
Can we simply declare 0-based as the standard for day of week and day
of
year, and 1-based for day of month, month of year, and week of year.
FWIW, that's what Date::ICal already had implemented, I believe.
Alternately, how about names like "day_of_week" and "day_of_week_1" or
something like that, so its _really_ clear what each does?
1. Declare one standard, but don't make March 1 be day-of-month 0, and
I'd prefer that March wasn't month 02. That just guarantees the extra
bytes in everyone's code, somewhere between calculation and output...
2003-00-10 what day is that? Today?? No, today should be (2003, 01,
11) at all times.
2002-12 is January 2003 ?!!! No, 2002-13 would be January 2003.
Even though I'm totally accustomed to 0-based indexing of months a la
localtime, it always reminds me of someone's email signature that says:
"There are 10 kinds of people in the world: those who get binary and
those who don't."
A good API shouldn't employ the equivalent of an inside joke.
Having a way to coerce the non-standard would also be good; but I'd
caution that someone might mistake 'day_of_week_1' as having something
to do with 'week 1', i.e., 'the first week'.
I propose the following:
month - 1-12
month_name - full name
month_name_abbr - abbreviated name
day - _day of month_ (makes sense in context of year() and
month() methods)
day_of_week - 0-6 (or 1-7, see earlier question)
day_name- full name
day_name_abbr - abbreviated name
I think this makes more sense than the Time::Piece API. The "name" is
the
full name, not the abbreviation. If you want the abbreviation, ask for
it.
2. Yes. All good. How about also using this convention for a consistent
way to indicate numerical vs. string?
As in:
Anything with _name - string
Anything with _of - numerical
Anything plain- numerical (does this work? day, month,
year, ...)
At times for clarity I also use:
Anything with _num - numerical
Anything with _str - string
I need _num at times when _name doesn't quite make sense for its
converse:
day_ord- e.g., 'Fifth' [the proper ('full') ordinal]
day_ord_num- e.g., '5th' [really an abbreviation]
because day_ord_name or day_name_ord might imply something like
'Wednesdayth'.
OTOH, this would be efficient:
day_ord- '5th'
day_ord_str- 'Fifth'
Not saying here that DateTime.pm should provide ordinals, but just that
it would be great to extend its method-naming scheme downstream, and an
unambiguous distinction between string and numerical returns would
help...
3. I vote for static DateTime objects. I think that makes it easier to
keep track of complicated namespaces, re-entries, etc., anyway.
4. For setters, I'm happy with usages like
$new_date = $date->clone( day => 5 );
and its implied
$date = $date->clone( day => 5 );
Thanks, Dave.
- Bruce
__bruce__van_allen__santa_cruz__ca__
Re: [mplspm]: Picking up the ball
On Thursday, January 9, 2003, at 04:35 PM, Dave Rolsky wrote: On Thu, 9 Jan 2003, Chris Josephes wrote: Why not just a DateTime object, like we already have a CGI object? I suppose that's possible too. I think the one thing the [EMAIL PROTECTED] cabal dislikes more than a new top-level namespace, is a single-level module name in a new top-level namespace ;) OTOH, if the goal is to provide a comprehensive set of datetime modules, there's an advantage to having part of the suite be _the_ DateTime module. I like the idea of a DateTime object. It's close to my own solution to marshaling date and time calcs into my applications -- my crude module creates a Calendar object with data and methods for print layouts and online presentations of calendars in arbitrary formats. It's trivially obvious what day of the month the 4th of July is on, but quick: in 2010, what day of the week will it fall on, and which weekend is it closer to so the layout can shade a long weekend? For Calendar layouts I've found that no one Date/Time module does everything I need, so my module has a standard set of methods that do typical calendaring calcs (about thirty for a given date, not considering clock time), plus a dispatcher that lets the specific application add its own library of calcs, maybe outputting in Spanish instead of English. The subroutines behind the method calls use whatever way I find optimal for that calc, and I swap modules in and out as I try new ones. My applications don't need to know. A meta-method I like for some applications is one that has the calendar object run all its calcs for every date in a range, then store the results in its own persistent table (file). The module then only has to execute (and memoize) calcs for dates that fall outside the pre-calculated range. Ten years is only ~3653 records -- a teeny database. Barring world revolution, November 7, 2006, will always be a Tuesday; for some applications why calculate again every time? Anyway, instead of my intervening module that collects the capabilities of various others into its own objects, a DateTime object created by a single module built from the base you're describing sounds good. As much as reasonable, as you suggest, it should grab good code from everywhere else, and only rely on other resources if that's truly optimal. I can't think of anything better than 'DateTime'. Thanks for reviving the effort, Dave. I could dedicate a few cycles to this project... 1; - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Proposed CPAN submission - Time::RateLimit
At 3:26 PM -0700 2002-05-29, Jay Soffian wrote: > "BVA" == Bruce Van Allen <[EMAIL PROTECTED]> writes: > >>> I think you meant $t - time; > >BVA> No, I'm fairly sure it works best the way Ilmari wrote it... > >I ran his code. It didn't work. I looked at it, switched it to time - $t, >it worked. Oops, you're right, but I think you meant meant $t - time; :-) -- - Bruce __bruce_van_allen__santa_cruz_ca__
Re: Proposed CPAN submission - Time::RateLimit
At 11:46 AM -0700 2002-05-29, Jay Soffian wrote:
> "IK" == Ilmari Karonen <[EMAIL PROTECTED]> writes:
>
>IK> Isn't this rather needlessly complex?
>
>Nope, not needlessly.
>
>IK> Essentially the same results can be achieved by simply counting
>IK> the (possibly inaccurate) time taken by sleep() as part of the
>IK> next iteration. Like this:
>
> use Time::HiRes qw(time sleep); # optional, for subsecond precision
> my $step = 0.1; # ten iterations per second
>
> my $t = time;
> while (1) {
> # do stuff...
> } continue {
> $t += $step; # watch out for rounding errors!
> my $delay = time - $t;
> sleep $delay if $delay > 0;
> }
>
>I think you meant $t - time;
No, I'm fairly sure it works best the way Ilmari wrote it...
>IK> This is guaranteed to maintain the correct average rate regardless
>IK> of any variations in the execution time of the loop, and will
>IK> automatically compensate for any systematic errors in sleep().
>IK> Non-systematic errors, of course, are unavoidable, but are
>IK> guaranteed not to propagate.
>
>Ah, but I don't want to maintain the average rate in all cases. This
>code was written to limit packets being sent out over the network. If
>the packet sending code falls behind significantly for some reason
>(say because someone paused the process), I don't want the code to run
>through the loop as quickly as possible till it brings the average
>rate back up. Rather, the code gives up if it has fallen too far
>behind and resets the rate (I'll make how far behind it can fall
>configurable).
>
How about:
use Time::HiRes qw(time sleep); # optional, for subsecond precision
my $step = 0.1; # ten iterations per second
my $max_delay = 5.0;# trigger for reset
my $t = time;
while (1) {
# do stuff...
} continue {
$t += $step; # watch out for rounding errors!
my $delay = time - $t;
$delay > $max_delay and &reset; # exit loop to reset
$delay > 0 and sleep $delay
}
--
- Bruce
__bruce_van_allen__santa_cruz_ca__
Re: Namespace changes
At 7:09 PM -0400 8/20/01, Rich Bowen wrote: >OK, just making sure that I had the support of a few folks. Remember, >I'm the one that proposed the change in the first place, so I still >think it's a good idea. Mostly, I just have not had time. > >So it seems, then, that the sentiment is still for this change. Yes from here. >And it >should probably be accompanied by a document of some variety that >explains the name divisions, and encourages people to use them. That sounds great, and -- take the time to give it a good effort. This kind of task only succeeds with clear thought and community buy-in. Thanks. -- - Bruce __bruce_van_allen__santa_cruz_ca__
