perl.datetime

perl.datetime http://www.nntp.perl.org/group/perl.datetime/ ... Copyright 1998-2013 perl.org Wed, 22 May 2013 06:24:25 +0000 ask@perl.org Re: DateTime setting invalid zone. by Bill Moseley On Wed, Mar 13, 2013 at 9:10 AM, Dave Rolsky <autarch@urth.org> wrote: > On Tue, 12 Mar 2013, Bill Moseley wrote: > > So, I found some old that wrapped a set_time_zone in an eval. >> >> my $dt = DateTime->new( >> year => 2013, >> month => 3, >> day => 10, >> hour => 2, >> minute => 4, >> time_zone => 'floating', >> ); >> >> eval { $dt->set_time_zone( 'America/Los_Angeles' ); }; >> >> print "$dt " . $dt->time_zone . "\n"; >> >> >> The code was using the eval to check if the timezone set failed, and if it >> did went on to do something else with $dt (like set to UTC). But, it >> seems like even if it fails the time zone gets set. The above returns >> this >> invalid time: >> >> 2013-03-10T02:04:00 >> DateTime::TimeZone::America::**Los_Angeles=HASH(**0x7fc4c2aafc90) >> >> My question is should DateTime associate that timezone to $dt if the >> set_time_zone call actually throws an exception? >> > > This is almost certainly a bug. > Ok, filed as: https://rt.cpan.org/Ticket/Display.html?id=83940 Thanks, -- Bill Moseley moseley@hank.org http://www.nntp.perl.org/group/perl.datetime/2013/03/msg7932.html Thu, 14 Mar 2013 11:39:42 +0000 Re: DateTime setting invalid zone. by Mark Stosberg On 03/13/2013 12:10 PM, Dave Rolsky wrote: > On Tue, 12 Mar 2013, Bill Moseley wrote: > >> So, I found some old that wrapped a set_time_zone in an eval. >> >> my $dt = DateTime->new( >> year => 2013, >> month => 3, >> day => 10, >> hour => 2, >> minute => 4, >> time_zone => 'floating', >> ); >> >> eval { $dt->set_time_zone( 'America/Los_Angeles' ); }; >> >> print "$dt " . $dt->time_zone . "\n"; >> >> >> The code was using the eval to check if the timezone set failed, and >> if it >> did went on to do something else with $dt (like set to UTC). But, it >> seems like even if it fails the time zone gets set. The above returns >> this >> invalid time: >> >> 2013-03-10T02:04:00 >> DateTime::TimeZone::America::Los_Angeles=HASH(0x7fc4c2aafc90) >> >> My question is should DateTime associate that timezone to $dt if the >> set_time_zone call actually throws an exception? > > This is almost certainly a bug. Would a fix to first clone the object, attempt to change time zone, and then only set the timezone on the original object if it succeeds? Mark http://www.nntp.perl.org/group/perl.datetime/2013/03/msg7931.html Wed, 13 Mar 2013 17:34:44 +0000 Re: DateTime setting invalid zone. by Dave Rolsky On Tue, 12 Mar 2013, Bill Moseley wrote: > So, I found some old that wrapped a set_time_zone in an eval. > > my $dt = DateTime->new( > year => 2013, > month => 3, > day => 10, > hour => 2, > minute => 4, > time_zone => 'floating', > ); > > eval { $dt->set_time_zone( 'America/Los_Angeles' ); }; > > print "$dt " . $dt->time_zone . "\n"; > > > The code was using the eval to check if the timezone set failed, and if it > did went on to do something else with $dt (like set to UTC). But, it > seems like even if it fails the time zone gets set. The above returns this > invalid time: > > 2013-03-10T02:04:00 > DateTime::TimeZone::America::Los_Angeles=HASH(0x7fc4c2aafc90) > > My question is should DateTime associate that timezone to $dt if the > set_time_zone call actually throws an exception? This is almost certainly a bug. -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/ http://www.nntp.perl.org/group/perl.datetime/2013/03/msg7930.html Wed, 13 Mar 2013 16:10:39 +0000 DateTime setting invalid zone. by Bill Moseley So, I found some old that wrapped a set_time_zone in an eval. my $dt = DateTime->new( year => 2013, month => 3, day => 10, hour => 2, minute => 4, time_zone => 'floating', ); eval { $dt->set_time_zone( 'America/Los_Angeles' ); }; print "$dt " . $dt->time_zone . "\n"; The code was using the eval to check if the timezone set failed, and if it did went on to do something else with $dt (like set to UTC). But, it seems like even if it fails the time zone gets set. The above returns this invalid time: 2013-03-10T02:04:00 DateTime::TimeZone::America::Los_Angeles=HASH(0x7fc4c2aafc90) My question is should DateTime associate that timezone to $dt if the set_time_zone call actually throws an exception? -- Bill Moseley moseley@hank.org http://www.nntp.perl.org/group/perl.datetime/2013/03/msg7929.html Wed, 13 Mar 2013 02:35:03 +0000 Re: How to correctly add a duration to not have it result in invalid date? by Andrew Davis Actually, most software that needs to do time arithmetic accurately does not use UTC internally. Leap seconds make calculations for future times problematic using UTC. See http://en.wikipedia.org/wiki/Leap_second Software in my field (space physics) uses epochs (seconds elapsed since an instant), or TAI. Conversion to "human friendly" dates/times such as UTC is done as the last step, and requires a leap second lookup table. Andrew J Davis (626) 429 0844 (cell) On Mar 8, 2013, at 11:48 PM, Jim Monty <jim.monty@yahoo.com> wrote: > Bill Moseley wrote: >> UTC is a timezone, too. > > UTC is only ever a "time zone" in implementations of computer models > of time and timekeeping such as Perl DateTime. In fact, UTC is, by > definition, NOT a time zone. It's the baseline reference time from > which time in zones are reckoned. A time expressed in UTC records a > moment in time (an "instant" in ISO 8601 parlance) without regard to > geography or geopolitical boundaries. It's the time everywhere and > nowhere. Zulu time. > > A time expressed in UTC is absolute and universal. > > I think this is the point Karen was emphasizing: don't record times > in a computer database in local time (in time zones) because these > expressions of time are rule-based and have too many anomalies in them, > which UTC representations of time do not have: a missing hour in some > days, a repeated hour in other days, etc. > >> In our database we use "timestamp with time zone" and it doesn't matter >> what timezone the database session uses as long as we use the timezone >> when parsing the column data. > > For me, it helps to think of the time zone as an attribute of a person > who needs to know what time it is, either now or when some even occurs. > The time zone is not an attribute of a moment in time. Time zones are > more about location than they are about time. > > So imagine if you abandoned all efforts to record instants in local time > and instead always recorded them in the single, universal reference > time, UTC. Perform all date and time arithmetic using these moments > uniformly recorded in UTC. Instead of storing the time zones along with > each moment in time, store the time zones of the people who need to > have the times expressed to them in their personal local time. > > This is what Microsoft Office Outlook does. I suspect it's how most > modern computer software handles timestamps. > > Jim Monty http://www.nntp.perl.org/group/perl.datetime/2013/03/msg7928.html Tue, 12 Mar 2013 08:57:44 +0000 Re: How to correctly add a duration to not have it result in invalid date? by Bill Moseley On Sun, Mar 10, 2013 at 4:59 PM, Jim Monty <jim.monty@yahoo.com> wrote: > > I believe this is how you might represent the RELATIVE time noon in > Caracas on October 12, 2018 using the iCalendar standard: > > DTSTART;TZID=America/Caracas:20181012T120000 > So, to compare that to some point in time (e.g. now() ) it must be turned into, well, a point in time like UTC based on what it knows about timezones -- at the moment. It's imposible to know what point in time that is until it actually happens, right? It's politics. Hard to imagine storing that form in a database and doing queries where offset calculations must be done at the time a query is run. Seems very expensive. > > The iCalendar standard specifies how to handle daylight/standard time > boundary cases such as when the same time occurs twice on the same day, > or when a time doesn't occur on a transitional day—like today in most > of the United States! > You know, yesterday I got curious and set both my Android phone and my wife's iPhone for a 2:30am alarm. I was curious when it would go off. Unfortunately, I told my wife about this and the experiment was quickly called off. -- Bill Moseley moseley@hank.org http://www.nntp.perl.org/group/perl.datetime/2013/03/msg7927.html Mon, 11 Mar 2013 05:01:29 +0000 Re: How to correctly add a duration to not have it result in invalid date? by Jim Monty Bill Moseley wrote: > I don't want to drag discussion on too much longer, and moving way off > the original topic... I don't see this discussion drifting off topic. I see it now getting to the very heart of the matter. > In a web app a user might enter a time, say 9:00am in the future, when > some event should happen. We know their timezone is America/New_York. > > So, we create a DateTime object DateTime->new ( hour => 9, time_zone => > 'America/New_York', ... ); > > Then we use DateTime::Format::Pg to format that to store in a "timestamp > with time zone" column. > > Am I correct that DateTime (or the formatter) does its best to determine > the *offset* from UTC at that time in the future and stores that? > > Would you implement that differently? Offsets from UTC don't record any useful information about time zones. For the kind of scheduling application you're describing, an offset from UTC isn't helpful because it doesn't record the important information you need to know about the future point in time at which something must occur; namely, where—in what geopolitical locale, or time zone—the user is asserting that some event must occur in the future. This is one of the reasons that, for the purpose of storing moments in time in a computer database, it's better to normalize their representation to a single reference time scale such as UTC. At the very least, doing this saves a lot of needless arithmetic with purposeless offsets. > But, between now and that future time politics could change DST resulting > in the event not really happening at 9am in New York on that day, correct? > That's a risk. > > There's too many ambiguities. Does the user really mean 9am in New York? > Or 9am in whatever their current time zone is on that day? Maybe in this > case should really store with a local time zone "9am America/New_York". > > Probably best to not schedule anything too far into the future... You can't reliably represent a future RELATIVE moment in time such as noon in Caracas, Venezula on October 12, 2018 using an ABSOLUTE instant you assert today. You can't be certain right now which instant noon will be on that future date in Caracas. So just guessing an ABSOLUTE instant now and storing that guess in a computer database won't suffice for the purpose of signaling some event to occur at that RELATIVE moment in the future and in that place—or in any other place at that same instant reckoned from noon in Caracas on October 12, 2018. You can, however, reliably represent future RELATIVE instants in computer software. You just need a protocol to do this. Storing ABSOLUTE timestamps alone—using any time scale or in any time zone— won't cut it. You can invent your own protocol, or you can use an existing one such as iCalendar. I believe iCalendar (RFC 5545) is designed to enable exactly the kind of RELATIVE time representation for scheduling events that you describe. The Perl DateTime documentation states: "The default time zone for new DateTime objects, except where stated otherwise, is the 'floating' time zone. This concept comes from the iCal [iCalendar] standard." The iCalendar standard defines three kinds ("forms") of times:     FORM #1: DATE WITH LOCAL TIME ("floating")     FORM #2: DATE WITH UTC TIME     FORM #3: LOCAL TIME AND TIME ZONE REFERENCE     (See http://tools.ietf.org/html/rfc5545#page-31.) I believe this is how you might represent the RELATIVE time noon in Caracas on October 12, 2018 using the iCalendar standard:     DTSTART;TZID=America/Caracas:20181012T120000 The iCalendar standard specifies how to handle daylight/standard time boundary cases such as when the same time occurs twice on the same day, or when a time doesn't occur on a transitional day—like today in most of the United States! Needless to say, there are plenty of Perl CPAN modules for handling iCalendar data, including DateTime::Event::ICal. (Disclaimer: I don't know the iCalendar standard well and I've never done the kind of scheduling software programming we're discussing here. What I've written in this email is based on the little research I did to try to answer your questions as best I could. If, knowing this, you say I should have kept my pie hole shut from the beginning, I won't argue with you. Hopefully, however, I've contributed at least one useful idea.) -- Jim Monty Tempe, Arizona USA http://www.nntp.perl.org/group/perl.datetime/2013/03/msg7926.html Sun, 10 Mar 2013 23:59:48 +0000 Re: How to correctly add a duration to not have it result in invalid date? by Bill Moseley I don't want to drag discussion on too much longer, and moving way off the original topic, but I do have an implementation question. On Fri, Mar 8, 2013 at 11:48 PM, Jim Monty <jim.monty@yahoo.com> wrote: > Bill Moseley wrote: > > UTC is a timezone, too. > Yes, poor choice of words. That sentence I wrote doesn't make much sense. I think I was saying to represent a *point in time* you need a timezone, where a timezone is an offset from UTC (including +00:00 offset). I was thinking about Postgresql at that time. But, that's still wrong for the word timezone. I'm not sure how Postgresql internally represents its "timestamp with time zone", but it looks more like it's a "timestamp with offset". 2012-09-07 15:26:40.338969-07 Offset is from UTC, of course, so that's always a point in time, correct? I think this is the point Karen was emphasizing: don't record times > in a computer database in local time (in time zones) because these > expressions of time are rule-based and have too many anomalies in them, > which UTC representations of time do not have: a missing hour in some > days, a repeated hour in other days, etc. > Again, I agree with Karen. There's no perfect answer, right? We (humans) mostly work with local times. Say, I set my alarm for 9am local time on March 8th 2015 (when DST is scheduled to begin) and then convert that to UTC and store. Then if DST is abolished between now and then my alarm will go off at the "wrong" local time. So, here's the implementation question. In a web app a user might enter a time, say 9:00am in the future, when some event should happen. We know their timezone is America/New_York. So, we create a DateTime object DateTime->new ( hour => 9, time_zone => 'America/New_York', ... ); Then we use DateTime::Format::Pg to format that to store in a "timestamp with time zone" column. Am I correct that DateTime (or the formatter) does its best to determine the * offset* from UTC at that time in the future and stores that? Would you implement that differently? But, between now and that future time politics could change DST resulting in the event not really happening at 9am in New York on that day, correct? That's a risk. There's too many ambiguities. Does the user really mean 9am in New York? Or 9am in whatever their current time zone is on that day? Maybe in this case should really store with a local time zone "9am America/New_York". Probably best to not schedule anything too far into the future... -- Bill Moseley moseley@hank.org http://www.nntp.perl.org/group/perl.datetime/2013/03/msg7925.html Sat, 09 Mar 2013 16:25:36 +0000 Re: How to correctly add a duration to not have it result in invalid date? by Jim Monty Bill Moseley wrote: > UTC is a timezone, too. UTC is only ever a "time zone" in implementations of computer models of time and timekeeping such as Perl DateTime. In fact, UTC is, by definition, NOT a time zone. It's the baseline reference time from which time in zones are reckoned. A time expressed in UTC records a moment in time (an "instant" in ISO 8601 parlance) without regard to geography or geopolitical boundaries. It's the time everywhere and nowhere. Zulu time. A time expressed in UTC is absolute and universal. I think this is the point Karen was emphasizing:  don't record times in a computer database in local time (in time zones) because these expressions of time are rule-based and have too many anomalies in them, which UTC representations of time do not have:  a missing hour in some days, a repeated hour in other days, etc. > In our database we use "timestamp with time zone" and it doesn't matter > what timezone the database session uses as long as we use the timezone > when parsing the column data. For me, it helps to think of the time zone as an attribute of a person who needs to know what time it is, either now or when some even occurs. The time zone is not an attribute of a moment in time. Time zones are more about location than they are about time. So imagine if you abandoned all efforts to record instants in local time and instead always recorded them in the single, universal reference time, UTC. Perform all date and time arithmetic using these moments uniformly recorded in UTC. Instead of storing the time zones along with each moment in time, store the time zones of the people who need to have the times expressed to them in their personal local time. This is what Microsoft Office Outlook does. I suspect it's how most modern computer software handles timestamps. Jim Monty http://www.nntp.perl.org/group/perl.datetime/2013/03/msg7924.html Sat, 09 Mar 2013 07:48:12 +0000 Re: How to correctly add a duration to not have it result in invalid date? by Bill Moseley On Fri, Mar 8, 2013 at 3:04 PM, Karen Etheridge <perl@froods.org> wrote: > > my $0.02: **always** store timestamps in ISO8601 format (UTC), or in unix > epoch (integer) format **only**. Local timezones should only get applied > when rendering data for user consumption - i.e. as late as possible, and > after all calculations have been performed. When processing timestamps > input by a user, convert to UTC as soon as possible, before storage and > before applying any math. > I know what you are saying and it's good advice. UTC is a timezone, too. If you want to represent a point in time so that you can later render it in a user's timezone or compare it to another time you must include the time zone. In our database we use "timestamp with time zone" and it doesn't matter what timezone the database session uses as long as we use the timezone when parsing the column data. If you have two DateTime objects (where is_floating is false) then AFAIK they can be compared regardless of time zone of each DateTime, object. That is, they both represent a point in time. When rendering we convert to the user's timezone (as they have chosen in their preferences). And as Zefram noted, "durations are not arithmetically well behaved", and so it using UTC is useful when working with durations for the DST issues I originally posted about. > There's a good (and lengthy) discussion at > https://metacpan.org/module/DateTime#How-DateTime-Math-Works, which ends > with very similar advice. > Good read, yes. -- Bill Moseley moseley@hank.org http://www.nntp.perl.org/group/perl.datetime/2013/03/msg7923.html Sat, 09 Mar 2013 01:24:36 +0000 Re: How to correctly add a duration to not have it result in invalid date? by Karen Etheridge On Fri, Mar 08, 2013 at 07:06:32AM -0800, Bill Moseley wrote: > With fifteen or so developers with all different levels of Perl skills not > all are going to understand or know the specifics of when duration math > might fail. And the hard part is it might not fail for months or years > after the code is written. > ... But, I'm > wondering if there's an idiom or rule I could provide them so that the math > will at least not fail. > Like, "always defined durations in terms of hours" (or seconds?) or "always > convert to UTC before adding a duration". my $0.02: **always** store timestamps in ISO8601 format (UTC), or in unix epoch (integer) format **only**. Local timezones should only get applied when rendering data for user consumption - i.e. as late as possible, and after all calculations have been performed. When processing timestamps input by a user, convert to UTC as soon as possible, before storage and before applying any math. There's a good (and lengthy) discussion at https://metacpan.org/module/DateTime#How-DateTime-Math-Works, which ends with very similar advice. http://www.nntp.perl.org/group/perl.datetime/2013/03/msg7922.html Fri, 08 Mar 2013 23:04:24 +0000 Re: How to correctly add a duration to not have it result ininvalid date? by Zefram Bill Moseley wrote: >Again, developers of varying skills come and go and work on existing code. > So, they may not have any idea that "$start_time" has a timezone or think >about DST issues. Or that a day isn't always 24 hours. So teach them. If they're going to be working a lot in this problem domain, they ought to learn enough about it to avoid making basic errors. >What if DatTime Duration objects had a flag to say do the math in UTC? > Would that avoid the problem if it possibly failing? That would make the issue of what a DateTime::Duration actually represents even more confusing than it already is. >In my experience the floating times open up other headaches. We store all >times with a timezone -- we would rarely have something like "9am your >time" because of the ambiguity. I'm not suggesting that *you* forget which timezone applies. I'm suggesting that you do the date arithmetic without telling *DateTime* to apply a timezone. Do the date arithmetic in "floating" timezone, and store the resulting local time along with the timezone name. To compare the current time against this stored threshold, take the current time, express it in the stored timezone, then take the resulting current local time and compare that (sans timezone) against the stored local time. -zefram http://www.nntp.perl.org/group/perl.datetime/2013/03/msg7921.html Fri, 08 Mar 2013 15:21:18 +0000 Re: How to correctly add a duration to not have it result in invalid date? by Bill Moseley Thanks for the responses! With fifteen or so developers with all different levels of Perl skills not all are going to understand or know the specifics of when duration math might fail. And the hard part is it might not fail for months or years after the code is written. Obviously, they should understand that adding a duration of, say, days may not mean exactly multiples 24 hours, and it could fail. But, I'm wondering if there's an idiom or rule I could provide them so that the math will at least not fail. Like, "always defined durations in terms of hours" (or seconds?) or "always convert to UTC before adding a duration". True, there's no easy solution. > > >What would happen if duration calculations were always done in UTC? > > That would avoid DST-based failures. It does so by applying a different > meaning of "day" from that which you're currently using. > Again, developers of varying skills come and go and work on existing code. So, they may not have any idea that "$start_time" has a timezone or think about DST issues. Or that a day isn't always 24 hours. $access->disable if $start_time->add( days => $day_limit ) < $now; That might be important contractually that it happens at some point instead of never. What if DatTime Duration objects had a flag to say do the math in UTC? Would that avoid the problem if it possibly failing? $access->disable if $start_time->add( days => $day_limit, in_utc => 1 ) < $now; > Maybe you actually want a definite UT time for the end of the period. > If that's the case, you probably want to interpret the duration in UT. > Or maybe you need the end of the period to be defined in local time. > In that case you'd be better just storing a notional local time without > regard to current projection of whether DST will skip it. (You do that > with DateTime by using the "floating" pseudo-timezone.) > In my experience the floating times open up other headaches. We store all times with a timezone -- we would rarely have something like "9am your time" because of the ambiguity. Thanks very much for the comments. -- Bill Moseley moseley@hank.org http://www.nntp.perl.org/group/perl.datetime/2013/03/msg7920.html Fri, 08 Mar 2013 15:07:16 +0000 Re: How to correctly add a duration to not have it result ininvalid date? by Zefram Bill Moseley wrote: >If $dt and $duration can be anything, what's the best way to prevent adding >a $duration to a $dt and having it land on a non-existent date? Depends how broad your "anything" class is for durations. Calendar durations are not arithmetically well behaved, and there are several distinct ways in which calendar datetimes can fail to exist. >What would happen if duration calculations were always done in UTC? That would avoid DST-based failures. It does so by applying a different meaning of "day" from that which you're currently using. You need to decide what you actually mean by "day" when describing these expiry periods. You also need to decide whether you actually need a definite DateTime to represent the end of the period. Consider, especially when the period is years long, that DST rules are liable to before the period ends. Currently you're performing the addition in local time and (by virtue of putting the result into a DateTime with specified time zone) converting the result to UT based on the current best guess of what offset the zone will have at that time. Maybe you actually want a definite UT time for the end of the period. If that's the case, you probably want to interpret the duration in UT. Or maybe you need the end of the period to be defined in local time. In that case you'd be better just storing a notional local time without regard to current projection of whether DST will skip it. (You do that with DateTime by using the "floating" pseudo-timezone.) -zefram http://www.nntp.perl.org/group/perl.datetime/2013/03/msg7919.html Fri, 08 Mar 2013 09:22:51 +0000 Re: How to correctly add a duration to not have it result in invaliddate? by Thomas Klausner Hi! On Thu, Mar 07, 2013 at 08:34:47PM -0800, Bill Moseley wrote: > Invalid local time for date in time zone: America/Los_Angeles I've had the same problem several times in the past (mostly in America/Sao_Paulo, which has the very stupid idea of making the switch to winter time at 0:00 (so there is no 00:00:00 - 00:59:59 on that day)). You can probably find the discussion in the archive. I suggested some fixes/workarounds, but they were rejected for being not correct. (They are not correct in a very technical sense, but would be extremly practical, IMO). > What would happen if duration calculations were always done in UTC? This is the correct (albeit complex) solution. Always do date math in UTC, and convert back to local time zone later. I find this solution not very practical or perlish, but other solutions probably won't be accepted into DateTime (or weren't when I tried the last time...) Greetings, domm -- #!/usr/bin/perl http://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} http://www.nntp.perl.org/group/perl.datetime/2013/03/msg7918.html Fri, 08 Mar 2013 09:17:50 +0000 How to correctly add a duration to not have it result in invalid date? by Bill Moseley Last night abou 2:15am we had some automated tests fail with this error: Invalid local time for date in time zone: America/Los_Angeles The problem was that (for some reason) we had a duration object of ( years => 7, days => 1 ) which we added to DateTime->now which ended up March 8, 2020 which is a DST change -- and 2:15am does not exist in that time zone on that date. If $dt and $duration can be anything, what's the best way to prevent adding a $duration to a $dt and having it land on a non-existent date? I realize that durations are a bit ambiguous, but is it reasonable to write something like $expires_time = $start_time->clone->add( days => $expire_days ); # or even ( years => 7, days => 1 ) like above and not have it throw an exception? I suspect most of us expect (and hope) that $expires_days in the future will exist. Or should we always write: $dt->add( hours => $expires_days * 24 ); What would happen if duration calculations were always done in UTC? $tz = $dt->time_zone; $dt->set_time_zone( 'UTC' ); $dt += $duration; $dt->set_time_zone( $tz ); What advice should I give to our developers about adding durations safely? It's a common operaton in our apps. Thanks, -- Bill Moseley moseley@hank.org http://www.nntp.perl.org/group/perl.datetime/2013/03/msg7917.html Fri, 08 Mar 2013 04:35:28 +0000 Re: DateTime locale names and wide characters by Dave Rolsky On Fri, 18 Jan 2013, Shane McCarron wrote: > The @data list is then sorted (by desc) and used to populate a <select> > element in a web form. Here's the weird thing. When I am using this under > Apache on a Linux platform in a CGI application, I get a warning that I am > printing 'wide characters' when I use data from the 'desc' as the content > of an 'option' element. What I *think* is that the data coming out of > DateTime::Locale is not properly encoded as Perl's utf8 internal encoding. > If I take the outout of the name() and native_name() methods and encode > them using "Encode", then it no longer complains. Is this expected > behavior? I think you have the cause a bit backwards. That warning means that you're printing data marked as UTF-8 to an output that expects to receive binary data. By default, all handles expect binary. Calling Encode::encode() turns Perl's UTF-8 flag _off_. I've always found this use of encode (and decode) confusing, since I'd expect encoding to produce UTF-8, which it does, but it produces _bytes_. The solution you're using is probably not the best idea. It's better to mark your output filehandle as UTF-8 with binmode() or by passing a layer to open: open my $fh, '>:encoding(UTF-8)', ...; In a webapp, you're probably printing to STDOUT so you can use binmode: binmode STDOUT, ':encoding(UTF-8)'; I'm not sure how this will interact with mod_perl's tying of STDOUT, though. -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/ http://www.nntp.perl.org/group/perl.datetime/2013/01/msg7916.html Thu, 31 Jan 2013 02:18:58 +0000 DateTime locale names and wide characters by Shane McCarron I have run into something sort of odd.... I wanted to give users of a web application a list of date locales to pick from for personalizing their displays. So I created a hash of mappings from each DateTime::Locale->ids() value to the name for each Locale object. The code looks something like this: my @data ; foreach my $id ( DateTime::Locale->ids() ) { my $ref = DateTime::Locale->load( $id ) ; if ($ref) { push(@data, { val => $id, desc => $ref->name() } ) ; } } The @data list is then sorted (by desc) and used to populate a <select> element in a web form. Here's the weird thing. When I am using this under Apache on a Linux platform in a CGI application, I get a warning that I am printing 'wide characters' when I use data from the 'desc' as the content of an 'option' element. What I *think* is that the data coming out of DateTime::Locale is not properly encoded as Perl's utf8 internal encoding. If I take the outout of the name() and native_name() methods and encode them using "Encode", then it no longer complains. Is this expected behavior? -- Shane McCarron halindrome@gmail.com http://www.nntp.perl.org/group/perl.datetime/2013/01/msg7915.html Sat, 19 Jan 2013 05:49:52 +0000 Re: The State of the TimeZone in Debian by gregor herrmann On Sat, 22 Dec 2012 22:36:28 +0000, Zefram wrote: > gregor herrmann wrote: > >Before I file ITP bugs and upload them, I'd like to have some review; > I'll look at them shortly. Thanks in advance! > >What I'm also missing is the big picture how those package relate to > >the good old DateTime::TimeZone with its tzfiles-converted-to-pm-files. > >It's supposed to use Time::OlsonTZ::Data at some point, right? > Right. There's a rewrite of DateTime::TimeZone, sitting in my repo, > that does away with the pm-per-zone modules and uses Time::OlsonTZ::Data > instead. Ok, thanks for the confirmation. > We scheduled the official replacement of DateTime::TimeZone > for 2012-09-01, but I was out of action for a few months due to a bout > of depression, so I missed that. I'm picking up the pieces now, and > we'll reschedule for some time in 2013. That's fine for us; currently we are in release freeze, so I guess at the time of the switch we'll be at the early stages of the next release cycle which is a good date for making the changes. > Whereas the current DateTime::TimeZone is volatile, due to including all > the timezone data, the rewritten DateTime::TimeZone will not be volatile. > The volatility is being localised in Time::OlsonTZ::Data (and, for you, > the underlying tzdata package). Ok. > >Do we need something else? I think we can skip > >Time::OlsonTZ::Download, since we want to use our tzdata anyway, > >right? And I think App::olson is also not required. > T:OTZ:Download is a development tool. The build process for T:OTZ:Data > uses it, even when working from local source, but your modified form > of T:OTZ:Data build could manage without it Ok. > if you tweak the prebuild script a bit. Actually I'd like to avoid building anything at all and using the tzfiles from tzdata directly at runtime; but you'll see this in my patch and cann tell us if this makes sense :) > There's no need for ordinary users to have T:OTZ:Download. Ok. > It would be nice to have App::olson packaged. (Preferably as "olson" > rather than "libapp-olson-perl", because it's intended to be used as > a command-line program rather than as a Perl module.) It is intended > for ordinary users. But it's not necessary to package it at this stage: > none of the timezone infrastructure depends on it. It is cleanly layered > on top of Time::OlsonTZ::Data. Good, let's keep this in mind for later. Thanks, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Eagles http://www.nntp.perl.org/group/perl.datetime/2012/12/msg7914.html Mon, 24 Dec 2012 05:40:34 +0000 The State of the TimeZone in Debian by gregor herrmann Following up on http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/2012-March/052645.html and the bug reports http://bugs.debian.org/660404 and http://bugs.debian.org/690908 I've now looked at some of the mentioned modules, and I've created preliminary packages for DateTime::TimeZone::Olson / libdatetime-timezone-olson-perl: http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libdatetime-timezone-olson-perl.git Time::OlsonTZ::Data / libtime-olsontz-data-perl: http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libtime-olsontz-data-perl.git Before I file ITP bugs and upload them, I'd like to have some review; especially on my patch for Time::OlsonTZ::Data, which makes the module use the tzfiles from tzdata in /usr/share/zoneinfo instead of duplicating them: http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libtime-olsontz-data-perl.git;a=blob;f=debian/patches/tzdata.patch;hb=HEAD http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libtime-olsontz-data-perl.git;a=blob;f=debian/rules;hb=HEAD Besides a general sanity check, some more tests for this patch would be welcome. What I'm also missing is the big picture how those package relate to the good old DateTime::TimeZone with its tzfiles-converted-to-pm-files. It's supposed to use Time::OlsonTZ::Data at some point, right? Do we need something else? I think we can skip Time::OlsonTZ::Download, since we want to use our tzdata anyway, right? And I think App::olson is also not required. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Bettina Wegner: Lied für meine verlassenen Freunde http://www.nntp.perl.org/group/perl.datetime/2012/12/msg7913.html Sun, 23 Dec 2012 09:09:40 +0000 Re: The State of the TimeZone in Debian by Zefram gregor herrmann wrote: >Before I file ITP bugs and upload them, I'd like to have some review; I'll look at them shortly. >What I'm also missing is the big picture how those package relate to >the good old DateTime::TimeZone with its tzfiles-converted-to-pm-files. >It's supposed to use Time::OlsonTZ::Data at some point, right? Right. There's a rewrite of DateTime::TimeZone, sitting in my repo, that does away with the pm-per-zone modules and uses Time::OlsonTZ::Data instead. We scheduled the official replacement of DateTime::TimeZone for 2012-09-01, but I was out of action for a few months due to a bout of depression, so I missed that. I'm picking up the pieces now, and we'll reschedule for some time in 2013. Whereas the current DateTime::TimeZone is volatile, due to including all the timezone data, the rewritten DateTime::TimeZone will not be volatile. The volatility is being localised in Time::OlsonTZ::Data (and, for you, the underlying tzdata package). >Do we need something else? I think we can skip >Time::OlsonTZ::Download, since we want to use our tzdata anyway, >right? And I think App::olson is also not required. T:OTZ:Download is a development tool. The build process for T:OTZ:Data uses it, even when working from local source, but your modified form of T:OTZ:Data build could manage without it if you tweak the prebuild script a bit. There's no need for ordinary users to have T:OTZ:Download. It would be nice to have App::olson packaged. (Preferably as "olson" rather than "libapp-olson-perl", because it's intended to be used as a command-line program rather than as a Perl module.) It is intended for ordinary users. But it's not necessary to package it at this stage: none of the timezone infrastructure depends on it. It is cleanly layered on top of Time::OlsonTZ::Data. -zefram http://www.nntp.perl.org/group/perl.datetime/2012/12/msg7912.html Sat, 22 Dec 2012 22:36:45 +0000 Shutting down the Sourceforge project for the DateTime suite by Dave Rolsky There's an old SF project that has an SVN repo with many, many DateTime modules - http://sourceforge.net/projects/perl-date-time AFAICT, no one is using the the SVN repo any more. The last holdout seemed to be Flavio Glock, and he just moved his projects to github. Unless someone objects, I'm going to delete this project at some point in the next few weeks. I'll make sure to grab an archive of the SVN repo before I do that, though. Dave Rolsky Compassionate Action for Animals - http://www.exploreveg.org/ VegGuide.Org - http://www.vegguide.org/ http://www.nntp.perl.org/group/perl.datetime/2012/12/msg7911.html Mon, 17 Dec 2012 19:28:35 +0000 Resolving floatting times using a reference time by Olivier Mengué Hi, I'm writing a Perl application for an embedded system, so I can't use DateTime and DateTime::TimeZone modules. I'm using only the system local timezone and it may have daylight saving changes. I need a function that will return an epoch time given a floating date+time (year, month, day, hour, minute, second) and an absolute epoch time. Unfortunately Time::Local doesn't seem to have this feature. Any suggestion on other modules, or on how to implement this? Here is below a broken implementation and a test suite with TODOs: use strict; use warnings; use Test::More; use Time::Local; sub timelocal_after { my ($sec, $min, $hour, $mday, $mon, $year, $after) = @_; my $time = timelocal($sec, $min, $hour, $mday, $mon, $year); # FIXME handle ambiguous times correctly return ($time >= $after) ? $time : undef } # Dates from 2012-10-28T02:00:00 to (non included) 2012-10-28T03:00:00 # are ambiguous $ENV{TZ} = 'Europe/Paris'; # 2012-10-28T01:59:59 => 2012-10-27T23:59:59Z is(timelocal_after(59, 59, 1, 28, 9, 112, 1), 1351382399); is(timelocal_after(59, 59, 1, 28, 9, 112, 1351382399), 1351382399); is(timelocal_after(59, 59, 1, 28, 9, 112, 1351382399+1), undef); # Resolved to the earlier time # 2012-10-28T02:00:00 => 2012-10-28T00:00:00Z is(timelocal_after(0, 0, 2, 28, 9, 112, 1), 1351382400); is(timelocal_after(0, 0, 2, 28, 9, 112, 1351382400), 1351382400); # Resolved to the later # 2012-10-28T02:00:00 => 2012-10-28T01:00:00Z { local $TODO = "Fix timelocal_after"; is(timelocal_after(0, 0, 2, 28, 9, 112, 1351382400+1), 1351382400+3600); is(timelocal_after(0, 0, 2, 28, 9, 112, 1351382400+3600), 1351382400+3600); # Past is(timelocal_after(0, 0, 2, 28, 9, 112, 1351382400+3601), undef); } # 2012-10-28T02:59:59 => 2012-10-28T00:59:59Z is(timelocal_after(59, 59, 2, 28, 9, 112, 1), 1351385999); is(timelocal_after(59, 59, 2, 28, 9, 112, 1351382400), 1351385999); is(timelocal_after(59, 59, 2, 28, 9, 112, 1351385999), 1351385999); # 2012-10-28T02:59:59 => 2012-10-28T01:59:59Z { local $TODO = "Fix timelocal_after"; is(timelocal_after(59, 59, 2, 28, 9, 112, 1351385999+1), 1351385999+3600); is(timelocal_after(59, 59, 2, 28, 9, 112, 1351385999+3600), 1351385999+3600); } is(timelocal_after(59, 59, 2, 28, 9, 112, 1351385999+3601), undef); # Offset changed to UTC+0100 # 2012-10-28T03:00:00 => 2012-10-28T02:00:00Z is(timelocal_after(0, 0, 3, 28, 9, 112, 1), 1351385999+3601); done_testing; http://www.nntp.perl.org/group/perl.datetime/2012/11/msg7910.html Wed, 28 Nov 2012 11:19:58 +0000 Re: Typo in my patch (not important, but hey) by Dave Rolsky On Mon, 19 Nov 2012, Martin Becker wrote: > Right after Dave published DateTime-0.78 I spotted a typo in > the description of a test that was insufficiently updated by > my patch for rt-79845. Thanks, I applied this. -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/ http://www.nntp.perl.org/group/perl.datetime/2012/11/msg7909.html Tue, 20 Nov 2012 15:02:01 +0000 Typo in my patch (not important, but hey) by Martin Becker Right after Dave published DateTime-0.78 I spotted a typo in the description of a test that was insufficiently updated by my patch for rt-79845. Sorry! -Martin diff -rup DateTime-0.78.orig/t/03components.t DateTime-0.78/t/03components.t --- DateTime-0.78.orig/t/03components.t 2012-11-16 18:40:40.000000000 +0100 +++ DateTime-0.78/t/03components.t 2012-11-19 14:25:47.000000000 +0100 @@ -260,7 +260,7 @@ is( $monday->day_of_week, 1, "Monday is $dt->set( nanosecond => 500_000_500 ); is( $dt->nanosecond, 500_000_500, 'nanosecond is 500,000,500' ); - is( $dt->microsecond, 500_000, 'microsecond is 500,001' ); + is( $dt->microsecond, 500_000, 'microsecond is 500,000' ); is( $dt->millisecond, 500, 'millisecond is 500' ); $dt->set( nanosecond => 499_999_999 ); http://www.nntp.perl.org/group/perl.datetime/2012/11/msg7908.html Tue, 20 Nov 2012 13:31:51 +0000 Re: Time::OlsonTZ::Data 0.201210 announcement by Bill Moseley On Mon, Nov 12, 2012 at 7:07 PM, Zefram <zefram@fysh.org> wrote: > Shortly available from all good CPAN mirrors: > > file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201210.tar.gz > size: 592407 bytes > md5: 138a1802d50d8315475b66f2c9811f0a > > Changes from the previous release: > > * Olson database version 2012j (code 2012j, data 2012j): 440 canonical > zones, 142 links > Hope this isn't too dumb of a question, but how does one determine when to upgrade to these newer modules. I was wondering about this because I noticed today that some of our production servers have DateTime from 2009 installed. Although there doesn't seem like any significant change in DateTime since then, maybe DateTime depends on something that does matter. -- Bill Moseley moseley@hank.org http://www.nntp.perl.org/group/perl.datetime/2012/11/msg7907.html Tue, 13 Nov 2012 08:43:48 +0000 Time::OlsonTZ::Data 0.201210 announcement by Zefram Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201210.tar.gz size: 592407 bytes md5: 138a1802d50d8315475b66f2c9811f0a Changes from the previous release: * Olson database version 2012j (code 2012j, data 2012j): 440 canonical zones, 142 links -zefram http://www.nntp.perl.org/group/perl.datetime/2012/11/msg7906.html Mon, 12 Nov 2012 19:07:45 +0000 RE: Test issue by Ursetti, Jerry The test passes with perl -w -T t/00-load.pl. It also passes with 'prove'. I took a guess and removed the -T flag from the test script and 'make test' now works. I think Module::Starter puts that into the 00-load.t test by default. Thanks for your help and sorry to bug you with something that turned out to not be related to DateTime. Jerry Ursetti __ __ __ /_ / | (_ /\/\ / /__/ _ ) / \ Financial Data Systems and Analytics Management (805)557-4212 (Work) (805)732-8484 (Blackberry) -----Original Message----- From: Karen Etheridge [mailto:perl@froods.org] Sent: Thursday, November 08, 2012 9:55 AM To: datetime@perl.org Subject: Re: Test issue 'prove' (in all but the most recent releases of Test::Harness - fixed here - https://github.com/Perl-Toolchain-Gang/Test-Harness/commit/18794a8565633ae08f048b9cf6c25b03be6e1020 ) automatically applies the -w flag to tests, so you can reproduce this error via perl -w t/00-load.t. That will also set you see more output from the test, which will hopefully lead you to the exact problem - something to do with your local timezone settings, as you surmised. On Thu, Nov 08, 2012 at 05:01:36PM +0000, Ursetti, Jerry wrote: > When I run 'make test', the test fails with this error: > > 'Error: Cannot determine local time zone' > > If I run the test script directly, 'perl -T t/00-load.t', the test passes. > > I tried using the $TZ environment variable (which is set to my time zone of PST8PDT) instead of 'local' in MODULE2. That gives me an 'Unknown error' with 'make test' but it still passes when run directly. CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information or otherwise be protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information or otherwise protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. http://www.nntp.perl.org/group/perl.datetime/2012/11/msg7905.html Thu, 08 Nov 2012 10:13:03 +0000 Re: Test issue by Karen Etheridge 'prove' (in all but the most recent releases of Test::Harness - fixed here - https://github.com/Perl-Toolchain-Gang/Test-Harness/commit/18794a8565633ae08f048b9cf6c25b03be6e1020 ) automatically applies the -w flag to tests, so you can reproduce this error via perl -w t/00-load.t. That will also set you see more output from the test, which will hopefully lead you to the exact problem - something to do with your local timezone settings, as you surmised. On Thu, Nov 08, 2012 at 05:01:36PM +0000, Ursetti, Jerry wrote: > When I run 'make test', the test fails with this error: > > 'Error: Cannot determine local time zone' > > If I run the test script directly, 'perl -T t/00-load.t', the test passes. > > I tried using the $TZ environment variable (which is set to my time zone of PST8PDT) instead of 'local' in MODULE2. That gives me an 'Unknown error' with 'make test' but it still passes when run directly. http://www.nntp.perl.org/group/perl.datetime/2012/11/msg7904.html Thu, 08 Nov 2012 09:55:37 +0000 Test issue by Ursetti, Jerry I've just run into an odd problem while testing one of my modules that has me stumped. I'm running Perl 5.8.8 on AIX 6.1. I'm testing a new module that uses one of my other modules. The second module uses the DateTime module and includes code to assign the local timezone to a variable. It sort of works like this: MyMODULE... ... Use MODULE2; Use DateTime; our $localtz = DateTime::TimeZone->new( name => 'local' ); I'm having trouble with the most basic test, just trying to use my module: #!perl -T use Test::More tests => 1; BEGIN { use_ok( 'MyMODULE' ); } diag( "Testing MyMODULE $ MyMODULE::VERSION, Perl $], $^X" ); When I run 'make test', the test fails with this error: 'Error: Cannot determine local time zone' If I run the test script directly, 'perl -T t/00-load.t', the test passes. I tried using the $TZ environment variable (which is set to my time zone of PST8PDT) instead of 'local' in MODULE2. That gives me an 'Unknown error' with 'make test' but it still passes when run directly. The only way I can get this to work with 'make test' is to hardcode the timezone in MODULE2, replacing 'local' with 'PST8PDT'. I really don't want to hardcode this. It seems like somehow the environment isn't quite right when I run the test via 'make test' so when DateTime tries to get the local timezone, it can't figure it out. Can I add something to Makefile.PL to make sure the timezone is in the environment? I checked the ExtUtils::MakeMaker pod but didn't see anything obvious that looked like it would set environment variables. I tried looking at the Test::Harness pod and code but didn't see anything there that might help explain what was going wrong, either. Does anyone have any ideas? Thanks. Jerry Ursetti __ __ __ /_ / | (_ /\/\ / /__/ _ ) / \ Financial Data Systems and Analytics Management (805)557-4212 (Work) (805)732-8484 (Blackberry) CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information or otherwise be protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information or otherwise protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. http://www.nntp.perl.org/group/perl.datetime/2012/11/msg7903.html Thu, 08 Nov 2012 09:01:51 +0000 Time::OlsonTZ::Data 0.201209 announcement by Zefram Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201209.tar.gz size: 593422 bytes md5: 250e48cb102b840a6c711989260fed53 Changes from the previous release: * Olson database version 2012i (code 2012i, data 2012i): 440 canonical zones, 142 links -zefram http://www.nntp.perl.org/group/perl.datetime/2012/11/msg7902.html Sat, 03 Nov 2012 14:07:50 +0000 Time::OlsonTZ::Data 0.201208 announcement by Zefram Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201208.tar.gz size: 592816 bytes md5: 094b652d130622d0e325fb015f96e256 Changes from the previous release: * Olson database version 2012h (code 2012h, data 2012h): 440 canonical zones, 142 links * in prebuild, handle new location for public domain notice in Olson tz-link.htm file -zefram http://www.nntp.perl.org/group/perl.datetime/2012/11/msg7901.html Thu, 01 Nov 2012 13:07:50 +0000 Re: "The default datetime format for the object’s locale" by Dave Rolsky On Thu, 25 Oct 2012, N Heinrichs wrote: > If the locale's definitions for the 'medium' formats are > wrong/outdated (see http://cldr.unicode.org/index/downloads) you could > propose an update to the locale class itself, but I am unsure of the > "official" way to do this. Note that DateTime::Locale is quite behind the CLDR data these days. Fixing this is kind of a pain in the ass, since the LDML data keeps changing (sometimes changing internal structure) and the DateTime::Locale code does a completely half-assed job of parsing the LDML documents. What I really want to do is write a proper Perl interface to libicu _or_ reimplement libicu in Perl, but that's a fairly big project. -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/ http://www.nntp.perl.org/group/perl.datetime/2012/10/msg7900.html Thu, 25 Oct 2012 15:16:09 +0000 Re: "The default datetime format for the object’s locale" by N Heinrichs Short answer: As of DateTime v0.72 on my local machine, %c is not directly configurable. A little more info: %c is hardcoded to use the locale's `datetime_format_default` (search for "strftime_patterns" in DateTime.pm) DateTime::Locale::ko does not override 'datetime_format_default'. Nor does it override 'default_date_format_length', or 'default_time_format_length', both of which default to 'medium' (see DateTime::Locale::root.) DT:Loc:ko's "medium" date/time formats are "yyyy\.\ M\.\ d\." and "a\ h\:mm\:ss", which is why you get the output below. So without modifying/overriding DateTime::Locale::ko, or dropping your use of %c in favor of a custom formatter, it may be difficult to fix your problem. If the locale's definitions for the 'medium' formats are wrong/outdated (see http://cldr.unicode.org/index/downloads) you could propose an update to the locale class itself, but I am unsure of the "official" way to do this. -Nate On Wed, Oct 24, 2012 at 2:36 AM, Bill Moseley <moseley@hank.org> wrote: > We have been using formats %c, %x and %X for localizing dates based on > Locale. Mostly works ok, but for Korean we are getting this: > > 2012. 10. 18. 오후 4:09:05 > > > where (I've been told) we would like this format: > > 2012년 10월 22일 월요일 오후 01:44 PDT > > > Is this formatting done in DateTime? I'm wondering how we can set the > default format used by %c for a given locale. > > In a web app what we are currently doing is > setting DateTime->DefaultLocale() per request. The DateTime objects are > inflated from database rows with DBIC. > > -- > Bill Moseley > moseley@hank.org http://www.nntp.perl.org/group/perl.datetime/2012/10/msg7899.html Wed, 24 Oct 2012 20:59:08 +0000 "The default datetime format for the object’s locale" by Bill Moseley We have been using formats %c, %x and %X for localizing dates based on Locale. Mostly works ok, but for Korean we are getting this: 2012. 10. 18. 오후 4:09:05 where (I've been told) we would like this format: 2012년 10월 22일 월요일 오후 01:44 PDT Is this formatting done in DateTime? I'm wondering how we can set the default format used by %c for a given locale. In a web app what we are currently doing is setting DateTime->DefaultLocale() per request. The DateTime objects are inflated from database rows with DBIC. -- Bill Moseley moseley@hank.org http://www.nntp.perl.org/group/perl.datetime/2012/10/msg7898.html Tue, 23 Oct 2012 10:37:01 +0000 Time::OlsonTZ::Data 0.201207 announcement by Zefram Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201207.tar.gz size: 587575 bytes md5: 659a8598a10f5a51b82d9b01427f4708 Changes from the previous release: * Olson database version 2012g (code 2012g, data 2012g): 440 canonical zones, 142 links -zefram http://www.nntp.perl.org/group/perl.datetime/2012/10/msg7897.html Wed, 17 Oct 2012 22:07:48 +0000 best way to to make an easy to use "local" DateTime object? by Mark Stosberg We have a large project that we would like to use our "local" time zone across many calls to DateTime. We are considering implementing something like this: ### package DateTimeX::Local; use parent 'DateTime'; # Calculate and cache the local time zone based on the OS. our $LocalTZ = DateTime::TimeZone->new( name => 'local' ); sub new { shift->SUPER::new( time_zone => $LocalTZ, @_ ) }; sub now { shift->SUPER::now( time_zone => $LocalTZ, @_ ) }; ### This works for us, but there are probably some other places where 'floating' is the default time zone... I see that 'floating' is hard-coded in a few places as the default time zone. It seems like a useful alternate design might be add this class method: DateTime->DefaultTimeZone($tz); ... and refactor to use that instead of the hardcoded value of 'floating' everywhere. We could then stick a call to DateTime->DefaultTimeZone somewhere, and developers could go on using DateTime as usual for the most part. The problem with the DateTimeX::Local solution is that someone could slip up and use DateTime directly, and everything would work until... after 7 or 8pm Eastern Time. :) . Also, the approach would break if a new location in DateTime was added that also used the 'floating' default as a hard-coded value. What do you think about the best way to set the time zone to "local" across a large project? Mark http://www.nntp.perl.org/group/perl.datetime/2012/10/msg7896.html Fri, 05 Oct 2012 15:24:38 +0000 Fwd: best way to to make an easy to use "local" DateTime object? by Mark Stosberg We have a large project that we would like to use our "local" time zone across many calls to DateTime. We are considering implementing something like this: ### package DateTimeX::Local; use parent 'DateTime'; # Calculate and cache the local time zone based on the OS. our $LocalTZ = DateTime::TimeZone->new( name => 'local' ); sub new { shift->SUPER::new( time_zone => $LocalTZ, @_ ) }; sub now { shift->SUPER::now( time_zone => $LocalTZ, @_ ) }; ### This works for us, but there are probably some other places where 'floating' is the default time zone... I see that 'floating' is hard-coded in a few places as the default time zone. It seems like a useful alternate design might be add this class method: DateTime->DefaultTimeZone($tz); ... and refactor to use that instead of the hardcoded value of 'floating' everywhere. We could then stick a call to DateTime->DefaultTimeZone somewhere, and developers could go on using DateTime as usual for the most part. The problem with the DateTimeX::Local solution is that someone could slip up and use DateTime directly, and everything would work until... after 7 or 8pm Eastern Time. :) . Also, the approach would break if a new location in DateTime was added that also used the 'floating' default as a hard-coded value. What do you think about the best way to set the time zone to "local" across a large project? Mark http://www.nntp.perl.org/group/perl.datetime/2012/10/msg7895.html Fri, 05 Oct 2012 15:24:36 +0000 Re: best way to to make an easy to use "local" DateTime object? by Zefram Mark Stosberg wrote: >For a project that does a lot of object creation, I the shorthand could >still be nice. It's very little shortening, and only for that one operation (explicit construction of a DateTime). Use it in your app if you like, but I don't think it's a candidate for addition to the main DateTime distro. -zefram http://www.nntp.perl.org/group/perl.datetime/2012/10/msg7894.html Mon, 01 Oct 2012 09:28:44 +0000 Re: best way to to make an easy to use "local" DateTime object? by Mark Stosberg On 10/01/2012 12:04 PM, Zefram wrote: > Mark Stosberg wrote: >> It seems like a useful alternate design might be add this class method: >> >> DateTime->DefaultTimeZone($tz); > > That would make the "default timezone" a global variable. If two modules > in one program both attempt to set it, you lose. If a module sets it > and the main program also does, you lose. So to be safe, you can never > set this in a reusable module. > > It gets worse. You're proposing to have this global variable used in > places that currently use a constant. Effectively, lots of code that > currently works fine by relying on the constant would now be reading the > new variable. So if your main program sets the variable to any other > value, and you're using any of the modules already on CPAN that rely on > the current behaviour, you lose. Thanks for that feedback. You made a good case against this approach. > Which timezone a particular DateTime object needs is not so much a > function of the application it's in, but of the way it's used in its > immediate surroundings. There are three main cases, corresponding > to the timezone designators "UTC" (for an absolute point in time), > "floating" (for a calendar time in no particular zone), and "local" > (for describing a point in time to users). A few applications need to > use multiple local timezones, due to people crossing localities. > > Each piece of code that generates DateTime objects should know the > broad purpose of those objects, and hence which kind of timezone they > should use. They should generally set the timezone slot explicitly. > Relying on the "floating" default is acceptable, but being explicit > about it is better. So, it sounds like being explicit is the way to go. The DateTimeX::Local approach would be explicit, while adding another layer of abstraction. It would be: DateTimeX::Local->new; vs: DateTime->new( time_zone => 'local' ); For a project that does a lot of object creation, I the shorthand could still be nice. Mark http://www.nntp.perl.org/group/perl.datetime/2012/10/msg7893.html Mon, 01 Oct 2012 09:20:17 +0000