jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From D G <>
Subject Re: new __Time function
Date Fri, 15 Jun 2012 15:35:08 GMT
Fair enough, I'll assume i'm the only one that needs a date other than
'right now' easily.

Same probably goes for stuff like 'hex2text', I added an extra view
mode to the TCP sampler which automatically converts hex to ascii. The
application I'm working with tends to require hex input, returning hex
output and I was tired of manually converting it :) If anyone is
interested I'll submit it.

I'll have a look at the bugs/enhancements list sometime and see if
there's anything I'd like to tackle.

On Fri, Jun 15, 2012 at 5:23 PM, sebb <> wrote:
> On 15 June 2012 16:12, D G <> wrote:
>> I'd like to point at that I wanted to keep it simple. Just __Time
>> extended with a _tiny_ bit of extra functionality: +/- n days.
>> If I can modify JMeter to suit my tastes you can be reasonably sure I
>> can write a little beanshell script in order to accomplish this.
>> I was simply surprised that there wasn't a 'tomorrow' function (__TIme
>> + 1) already and offered to implement one but the feature creep so far
>> is quite impressive :)
>> So just to be clear: I agree with you. But I'm asking the community
>> what they'd like and that seems to be: 'everything'. Which I admit has
>> a use case of course.
> I'm not sure it's true that the community want 'everything'.
> There have not yet been any use cases (apart from yours).
> There have been some implementation suggestions, but AFAICT that is
> from a developer point of view, not a user.
>> On Fri, Jun 15, 2012 at 5:04 PM, Sergio Boso <> wrote:
>>> Il 15/06/2012 10:13, D G ha scritto:
>>>> This all started as 'now + n days', so the __timeAdd methods works on
>>>> a now + something manner.
>>>> New proposal:
>>>> __timeAdd(format, number*, m|h|d|w|M|y**, parseString, parseFormat,
>>>> variable)
>>>> where parseString is the string to be parsed into a date object and
>>>> ParseFormat is the format of the string to be parsed.
>>> I use to do that kind of things in Javascript, in a BSF pre or post
>>> processor.
>>> It takes just few lines of code, according to what you want to do.
>>> I'm keen to understand what would be the advantages of an integrated
>>> solution.
>>> regards
>>> Sergio
>>>> My criticism would be the growing number of (optional) parameters but
>>>> it's too easy to lose __Functions somewhere in a test. Don't like
>>>> using two functions to accomplish a task :)
>>>> Another would be requiring some knowledge of how Java parses data.
>>>> Though that should be reasonably trivial to learn for most strings.
>>>> Also, it would be quite easy to allow parseString to accept a
>>>> float/epoch time and work with that.
>>>> Thoughts?
>>>> Regards,
>>>> Daniel
>>> --
>>> In caso di erronea ricezione da parte di persona diversa, siete pregati di
>>> eliminare il messaggio e i suoi allegati in modo definitivo dai vostri
>>> archivi e di volercelo comunicare immediatamente restituendoci il messaggio
>>> via e-mail al seguente
>>> <>
>>> L’interessato può, inoltre, esercitare tutti i diritti di accesso sui propri
>>> dati previsti dal decreto 196/2003, tra i quali i diritti di rettifica,
>>> aggiornamento e cancellazione, inviando un messaggio
>>> all’ <>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message