I'm reading a date in a field, ex: 23/01/2015 11:04:06.265842 I would like to get 23/01/2015 11:04:06.26.
The purpose is to compare two datetime and get the result time, for example 2.16 seconds between the two times.
Actually I'm doing : fields["Date"]=os.date("%c", fields["frame.time_epoch"])
frame.time_epoch come from a .pcap file (wireshark)
EDIT:
You can't get millisecond precision with os.date - the maximum resolution it allows is second (see it here http://www.lua.org/pil/22.1.html)
You could try adding it yourself:
local epoch = fields["frame.time_epoch"]
local milliseconds = (epoch - math.floor(epoch))*1000
fields["Date"]=("%s.%03d"):format(os.date("%c", epoch), milliseconds)
Related
I have a script that needs two timestamps, one for 'today' at 02:30 and one for 'tomorrow' at 02:30. To generate the dates was fairly easy, using;
date1=${__time("yyyy.MM.dd 02:30:00")}
date2=${__timeShift("yy.MM.dd 02:30:00",,P1D,,)}
But the POST request needs the dates in Epoch format. How can I convert the output of the above into Epochs?
An option that I found was to use;
date1a=date1.getTime().toString()
But that didn't work (no signature of method). Related to that I did find a jmeter 5.3 bug where the dateutil.jar is missing, but adding it made no difference.
There are lots of options for converting Epoch to human readable, but they aren't reversible processes.
Alternatively, is there a way of calculating the Epoch directly, again for 'today' at 2:30 and 'tomorrow' at 2:30?
Don't inline JMeter Functions or Variables into scripts, as per JSR223 Sampler documentation
The JSR223 test elements have a feature (compilation) that can significantly increase performance.
When using this feature, ensure your script code does not use JMeter variables or JMeter function calls directly in script code as caching would only cache first replacement. Instead use script parameters
I believe you can achieve your goal using good old SimpleDateFormat, example code to parse your string and add 24 hours to it:
def today = new java.text.SimpleDateFormat('yyyy.MM.dd hh:mm:ss').parse('2020.11.06 02:30:00')
log.info('Today: ' + today)
def tomorrow = new Date(today.getTime() + 86400000L)
log.info('Tomorrow: ' + tomorrow)
log.info('Today epoch : ' + today.getTime())
log.info('Tomorrow epoch: ' + tomorrow.getTime())
Demo:
More information on Groovy scripting in JMeter: Apache Groovy - Why and How You Should Use It
Trying to convert time as a string to a time variable.
Use Date/Dates/Convert String to Date...... for format I use %H:%M:%S....
Here is the syntax from the GUI
[Convert String Variables to Date]
BSkystrptime (varNames = c('Time'),dateFormat = "%H:%M:%S",prefixOrSuffix = "prefix",prefixOrSuffixValue = "Con_",data = "Dataset2")
BSkyLoadRefreshDataframe(dframe=Dataset2,load.dataframe=TRUE)
A screen shot of result is attached....
Compare variables Time [string] to Con_Time [date/time]
The hours are 2 hours out [wrong!] - the Minutes and Seconds are correct.
What am I doing wrong here?
Screen Shot
I believe you are running into a known issue with a prior release of BlueSky Statistics. This issue is fixed with the current stable release available on the download page.
The reason for this was although the time is converted correctly into the local time zone, BlueSky Statistics was reading the time zone in the local time zone and converting it to UTC.
You are probably +2 hours ahead of UTC, so you are seeing the time move 2 hrs back. Give us a couple of days to post a patch.
You can also confirm this by writing and executing the following syntax in the syntax window
Dataset2$Con_Time
I need a function that returns the local time in milliseconds on the CPP target.
I tried Haxe's Date class, but Date.now() gives me the time in seconds.
Sys.time() * 1000.0 - http://api.haxe.org/Sys.html#time
Gives the most precise timestamp value (in seconds)
To be clear, I tried this and got millisecond resolution on the cpp target. Sys is available on cpp, cs, java, macro, neko, php and python.
You could try Date.now().getTime(), however:
Returns the timestamp of the date. It might only have a per-second precision depending on the platforms.
A fast way of getting a timestamp would be to use the haxe.Timer.stamp() method.
Example:
import haxe.Timer;
var timestamp:Float = Timer.stamp(); // return a timestamp in seconds with fractions
Note that the value itself might differ depending on platforms, only differences between two values make sense.
Anyone know what sort of timestamp this is?
130580051014610352
I believe it's ticks since 1970 or something, common in .NET.
I need to convert it to YYYYMMDDHH24MISS timestamp in AutoHotkey.
Appreciate any help
It would appear to be a Windows file time. Quoting MSDN:
A file time is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated Universal Time (UTC).
However, keep in mind that the file system where you obtained this timestamp is important.
NTFS properly stores file times based on the UTC time.
FAT16 and FAT32 store file times based on the local time.
This can be a problem if (for example) you save a file to a thumbdrive on one computer, then load it from another in a different time zone.
It can also be problematic within a single timezone because local times can't disambiguate between values that are in a daylight saving time fall-back transition period.
Assuming the value came from NTFS and is therefore UTC-based, you can get the UTC time in .NET code by using DateTime.FromFileTimeUtc, or you can get the equivalent local time by using DateTime.FromFileTime.
I'm not sure exactly what the equivalent code would be in AutoHotkey's scripting language, but I did notice that it already has a built-in function for getting a timestamp from a file, if that's what you're doing.
Someone posted a solution in AHK forums:
TicksToTime(FileTicks,UTC="")
{ ; 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601 (UTC)
; FileTicks := 131817689607677716
FileSeconds := FileTicks // 10000000
DateTimeUTC := 1601
DateTimeUTC += FileSeconds, S
if (UTC = 1)
Return DateTimeUTC
; LocalTicks := FileTimeToLocalFileTime(FileTicks) ;;;
VarSetCapacity(FileTime, 8, 0)
VarSetCapacity(LocalTime, 8, 0)
NumPut(FileTicks, FileTime, "UInt64")
DllCall("FileTimeToLocalFileTime", "Ptr", &FileTime, "Ptr", &LocalTime)
FileSeconds := (NumGet(LocalTime, "UInt64") // 10000000)
DateTimeLoc := 1601
DateTimeLoc += FileSeconds, S
;utc time = DateTimeUTC
Return DateTimeLoc
}
I'm using the following functions:
# The epoch used in the datetime API.
EPOCH = datetime.datetime.fromtimestamp(0)
def timedelta_to_seconds(delta):
seconds = (delta.microseconds * 1e6) + delta.seconds + (delta.days * 86400)
seconds = abs(seconds)
return seconds
def datetime_to_timestamp(date, epoch=EPOCH):
# Ensure we deal with `datetime`s.
date = datetime.datetime.fromordinal(date.toordinal())
epoch = datetime.datetime.fromordinal(epoch.toordinal())
timedelta = date - epoch
timestamp = timedelta_to_seconds(timedelta)
return timestamp
def timestamp_to_datetime(timestamp, epoch=EPOCH):
# Ensure we deal with a `datetime`.
epoch = datetime.datetime.fromordinal(epoch.toordinal())
epoch_difference = timedelta_to_seconds(epoch - EPOCH)
adjusted_timestamp = timestamp - epoch_difference
date = datetime.datetime.fromtimestamp(adjusted_timestamp)
return date
And using them with the passed code:
twenty = datetime.datetime(2010, 4, 4)
print(twenty)
print(datetime_to_timestamp(twenty))
print(timestamp_to_datetime(datetime_to_timestamp(twenty)))
And getting the following results:
2010-04-04 00:00:00
1270339200.0
2010-04-04 01:00:00
For some reason, I'm getting an additional hour added in the last call, despite my code having, as far as I can see, no flaws.
Where is this additional hour coming from?
# Ensure we deal with `datetime`s.
date = datetime.datetime.fromordinal(date.toordinal())
(That's chopping off the time-of-day completely, as ‘ordinal’ is only a day number. Is that what you meant to do? I suspect not.)
Anyway, as Michael said, datetime.fromtimestamp gives you a naïve datetime corresponding to what local time for that POSIX (UTC) timestamp would be for you. So when you call —
date = datetime.datetime.fromtimestamp(adjusted_timestamp)
you're getting the local time for the POSIX timestamp representing 2010-04-04T00:00:00, which of course in BST is an hour ahead. This doesn't happen in the return direction because your epoch is in January, when BST is not in force. (However your EPOCH would also be completely off if you weren't in the UK.)
You should replace both your uses of datetime.fromtimestamp with datetime.utcfromtimestamp.
It's sad that datetime continues the awful time tradition of keeping times in local time. Calling them ‘naïve’ and taking away the DST flag just makes them even worse. Personally I can't stand to use datetime, preferring integer UTC timestamps for everything (converting to local timezones for formatting only).
Judging by your profile, you're in the UK. That means you're currently running on UTC+1 due to DST.
If I take your timestamp and run it through datetime.fromtimestamp on Python 2.6 (I know you use Python 3, but this is what I have), that shows me that it believes it refers to 2010-04-04 02:00:00 - and I'm in CEST, so that's UTC+2.
Running datetime.fromtimestamp(0), I get that the epoch is 1970-01-01 01:00:00. This then shows me that it is correctly adding only a single hour (since January 1st is outside of DST, and the epoch is midnight UTC on that date, it would be 01:00 here).
In other words, your problem is that you're sending in a time which has DST applied, but datetime_to_timestamp treats it as if DST didn't exist. timestamp_to_datetime, however, applies the DST.
Unfortunately, I don't know enough Python to know how you would solve this, but this should at least give you something to go on.