translate human-readable time shorthand

[Peter Makholm]

So we should try to agree that one minute of duration is 60 seconds,
one hour is 60 minutes, one day is 24 hours, and one week is 7 days,
regardless of when those periods start or stop.

Depending on the context I think that '1 day' could mean both a 24 hours
duration or the next day at the same (local) time. When the duration
is the primary object I would understand 24 hours and when the point in
time is the primary object I would understand at the same time the next
day.

In some cases I use the same interpretation when I change time zone due
to travel (at least for time zone changes within a few hours). So if I
have a recurring task I have to perform every 2 days I would default to
do it on the same time of the day accoridng to the local time.

For month and year I think I would make the same distinctions, where the
duration would be some sort of normalized duration (30 days/365 days)
and the point in time would depend on the specific month or year.

A recurring monthly meeting would by default be at the same day of the
month. For a duration of several months I would probably just consider
the difference negligible.

//Makholm

 

[Jim Gibson]

all these are very wise and clever except ... that the OP is missing !

The OP moved his question over to comp.lang.perl.modules -- still
looking for a module that would do the conversion for him. He also made
it clear that the context of the question is in the time delays used by
'at', the Unix task scheduling utility, so anything longer than a week
is probably irrelevant, and the interpretation of months and years is
moot.

 

[Tim McDaniel]

He also made it clear that the context of the question is in the time
delays used by 'at', the Unix task scheduling utility

I have the impression that cron (as an analogy) has had extensive work
to make corner cases work, like 1-3 AM on daylight-saving change day,
or other clock adjustments. I mention that only as an example about
how time handling can be tricky and so I would be more inclined to use
a module that shows some signs of handling intervals properly.

 

[Rainer Weikusat]

I have the impression that cron (as an analogy) has had extensive work
to make corner cases work, like 1-3 AM on daylight-saving change day,
or other clock adjustments. I mention that only as an example about
how time handling can be tricky and so I would be more inclined to use
a module that shows some signs of handling intervals properly.

The problem is underspecified and can't be solved 'calendarically
correct' based on the available information. More accurately, the
problem consists of two subproblems, namely 1) parse the string in order to
find the number/unit combinations in it. This is trivial and can be
done with a single line of code. And then 2) 'interpret this
information in a suitable way'. Because 2) can't be solved without
information the OP isn't willing to provide, all example code which
was posted necessarily solved problem 1).

 

[Rainer Weikusat]

(e-mail address removed) (Tim McDaniel) writes:

[...]

I have the impression that cron (as an analogy) has had extensive work
to make corner cases work, like 1-3 AM on daylight-saving change
day,

Since this is such a nice illustration of the 'garbage in - garbage
out' issue: What precisely do you mean by 'work'? Surely not 'should
run for three hours every day except that it should run for fewer
than three hours on some random day in spring and for fewer than three
hours on some random day in fall if the system default time zone
currently happens to have some "I'm an early riser and it really
pisses me off that others are still asleep !!!!"[*] voodoo convention?

[*] IIRC, Wikipedia states that "Random Clockjump Day" was invented
before 1914 by some British guy who 'felt lonely' on his seriously
early morning ridw ...

 

[Rainer Weikusat]

(e-mail address removed) (Tim McDaniel) writes:

[...]

I have the impression that cron (as an analogy) has had extensive work
to make corner cases work, like 1-3 AM on daylight-saving change
day,

Since this is such a nice illustration of the 'garbage in - garbage
out' issue: What precisely do you mean by 'work'? Surely not 'should
run for three hours every day except that it should run for fewer
than three hours on some random day in spring and for more than three
hours on some random day in fall if the system default time zone
currently happens to have some "I'm an early riser and it really
pisses me off that others are still asleep !!!!"[*] voodoo convention?

[*] IIRC, Wikipedia states that "Random Clockjump Day" was invented
before 1914 by some British guy who 'felt lonely' on his seriously
early morning ride ...

 

[Tim McDaniel]

The problem is underspecified and can't be solved 'calendarically
correct' based on the available information.

Quite true, quite true. If they really do want _duration_, then now +
duration in UTC -> convert to a timezone at need is the way.

 

[Tim McDaniel]

What if there is already a space there?

Then there are two spaces, which the module accepts, and since the
string is only to be used for parsing, it doesn't have to look pretty.

Yeah, you could strip leading whitespace. But the module actually
implements [,\s]+ to delimit fields, as I recall, so if you want
something minimal, you'd have to strip that.