[rt.cpan.org #79845] [PATCH] sub-second precision and rounding
URL: https://rt.cpan.org/Ticket/Display.html?id=79845
On Tue Sep 25 07:27:53 2012, MHASCH wrote:
To demonstrate that the current rounding behaviour is not
quite thought through, try:
use DateTime 0.76;
my $d = DateTime-new(
year = 2012,
month = 9,
day=25,
hour =12,
minute =39,
second =59,
nanosecond = 999876000,
time_zone = 'Europe/Berlin',
);
print $d-strftime('%H:%M:%S.%3N'), \n;
This will print 12:39:59.1000 rather than 12:39:59.999.
And no, please don't make it print 12:40:00.000 either.
Rounding is just not the right thing to do by default.
There were a few RT tickets about this and I've thought about it a fair
bit. I think your solution is right.
This gets really messy with a datetime like 2011-12-31T23:59:59.999
To round properly we'd have to round every single unit, including the
year! There's really no way to do this in strftime and format_cldr
anyway, since you can only dictate the formatting _per unit_, so you
might not even be printing out all the units which need rounding.
Re: best way to to make an easy to use local DateTime object?
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. What do you think about the best way to set the time zone to local across a large project? 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. -zefram
