Re: Daylight-Saving Causes Twin Arrival Pickle
Rick Measham wrote: http://www.wral.com/news/local/story/2011296/ When Parliament was debating the introduction of DST in the UK, as a wartime measure in 1916, Lord Balfour (a member of the House of Lords, the upper chamber of Parliament), with the usual aristocratic concern for matters of inheritance, noted precisely this problem with it: Supposing some unfortunate lady was confined with twins and one child was born 10 minutes before 1 o'clock. ... The elder child would be registered as being born at 12.50, but the younger child's birth, ten minutes later, would be registered at 12.00. ... the time of birth of the two children would be reversed. ... Such an alteration might conceivably affect the property and titles in that House. We can only hope that times of birth are annotated with the timezone abbreviation where such ambiguity occurs. I rather suspect that it's not standard practice, though. My understanding (from a British nurse) is that hospital clocks are not especially accurate, so that they can't be relied upon for minute-level accuracy anyway. The birth times of me and my three siblings (all single births) were all recorded as exact multiples of five minutes, so I presume there's some rounding going on there, but I'm at a loss to determine whether the rounding performed was down or to nearest. There's not much concern for precise timing in evidence. -zefram
Re: Patch for DateTime::Format::W3CDTF to respekt second fragment part
Jonathan Leffler wrote: Or, what happens if there are 10 digits after the decimal point. That's what the substr() is for. Yeah, mostly academic, except I'm working towards a time type (not for Perl per se) that extends down to picoseconds (and up to 10^12 years, too). At least 105 bits, then. TAI64 covers nearly 10^12 years, of course, and the extension TAI64NA goes down to attoseconds in a 128-bit format. What's the concept behind your type? Personally I like to use bignum rational arithmetic, for unlimited resolution. Performance is atrocious with the Perl bignum libraries, unfortunately. -zefram
Re: Patch for DateTime::Format::W3CDTF to respekt second fragment part
Zefram [EMAIL PROTECTED] wrote:
Re: Patch for DateTime::Format::W3CDTF to respekt second fragment part
Julian Haupt wrote:
+if ($date =~ s/\.(\d+)$// )
+{
+ my $fraction = $1;
+ $p{'nanosecond'} = (1 / $fraction) * 10**9;
+}
That inversion can't be right. Surely you mathematically want
$p{'nanosecond'} = 0.$fraction * 10**9;
but actually the nanoseconds member is supposed to be an integer, and
it would be better to avoid floating-point arithmetic entirely:
$fraction = substr($fraction, 0, 9);
$fraction .= 0 x (9 - length($fraction);
$p{'nanosecond'} = 0 + $fraction;
Beware the picosecond!
Or, what happens if there are 10 digits after the decimal point. I've no
idea what -3 zeroes looks like, but the answer is unlikely to be correct.
Yeah, mostly academic, except I'm working towards a time type (not for
Perl per se) that extends down to picoseconds (and up to 10^12 years,
too).
--
Jonathan Leffler ([EMAIL PROTECTED])
STSM, Informix Database Engineering, IBM Information Management Division
4100 Bohannon Drive, Menlo Park, CA 94025-1013
Tel: +1 650-926-6921Tie-Line: 630-6921
I don't suffer from insanity; I enjoy every minute of it!
NB: with effect from 2007-11-28, my address and phone number change to:
4400 N First St, San Jose, CA 95134-1257
Tel: +1 408-956-2436 T/L: 475-2436
smime.p7s
Description: S/MIME Cryptographic Signature
