Skip Menu |

This queue is for tickets about the Time-Date CPAN distribution.

Report information
The Basics
Id: 107095
Status: resolved
Priority: 0/
Queue: Time-Date
People
Owner: Nobody in particular
Requestors: ARISTOTLE [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Mon Sep 14 20:44:40 2015 ARISTOTLE [...] cpan.org - Ticket created
Subject: Add method for converting to Unix epoch time
Please consider adding an ->epoch method. (That is the “duck type” conventional name for the method that does this, as far I’ve found in a half-dozen CPAN datetime modules.) I have found that a lot of modules have bugs in their strftime (or maybe not, but in any case they at least have *different* bugs from everyone else’s strftimes), whereas their ->epoch tends to be correct. Considering all the edge cases a ->strftime needs to account for, and how simple ->epoch’s job is in comparison, that’s really no surprise. The combination of providing ->epoch and ->from_epoch makes it easy for code to be written to be datetime-module-agnostic.
  Fri Jul 21 17:10:03 2017 JACOBG [...] cpan.org - Correspondence added
On Mon Sep 14 20:44:40 2015, ARISTOTLE wrote: Show quoted text
> Please consider adding an ->epoch method. (That is the “duck type” > conventional name for the method that does this, as far I’ve found in > a half-dozen CPAN datetime modules.) > > I have found that a lot of modules have bugs in their strftime (or > maybe not, but in any case they at least have *different* bugs from > everyone else’s strftimes), whereas their ->epoch tends to be correct. > Considering all the edge cases a ->strftime needs to account for, and > how simple ->epoch’s job is in comparison, that’s really no surprise. > > The combination of providing ->epoch and ->from_epoch makes it easy > for code to be written to be datetime-module-agnostic.
You can get the epoch by calling $date->{"epoch"}. I don't really care to be compatible with the interfaces of other date modules, I just want to define something that makes sense to me.
  Fri Jul 21 17:10:04 2017 The RT System itself - Status changed from 'new' to 'open'
  Fri Jul 21 23:32:27 2017 ARISTOTLE [...] cpan.org - Correspondence added
On Fri Jul 21 17:10:03 2017, JACOBG wrote: Show quoted text
> I don't really care to be compatible with the interfaces of other date modules, I just > want to define something that makes sense to me.
That’s really too bad. In XML::Atom::SimpleFeed, where a timestamp is needed, I accept some sort of datetime object if the user wants to pass one. Ideally the code would accept absolutely all possible datetime objects, but ducktyping every possible datetime module at runtime is unreasonably expensive. But I’ve found that `eval { $dt->epoch }` covers a bunch of modules, and no other interface is shared by more than two different datetime modules, so for every module I can’t support with ->epoch, I’d have to support that module individually. So I only support datetime modules that have an ->epoch. But for users of your module that means they have to write extra code to use it with mine. Show quoted text
> You can get the epoch by calling $date->{"epoch"}.
But that means it’s about as cheap as can be for you to support the method: just add a `sub epoch { $_[0]{epoch} }` and you’re done.
  Wed Nov 01 13:01:49 2017 JACOBG [...] cpan.org - Correspondence added
I added the sub.
  Wed Nov 01 13:01:49 2017 JACOBG [...] cpan.org - Status changed from 'open' to 'resolved'
  Wed Nov 01 16:28:13 2017 ARISTOTLE [...] cpan.org - Correspondence added
On Wed Nov 01 13:01:49 2017, JACOBG wrote: Show quoted text
> I added the sub.
Thank you!