Forum Discussion
Cirrocumulusclock clicks -milliseconds overflow time?
But I can't find anywhere that explicitly says what the implementation of it is in iRules (Apart from -milliseconds is the highest resolution, and that's from memory... I can't seem to find the posting... NEDs rule is interesting though. That seems to assume that the hi res timer is an offset from the current second... Again I can't find anywhere that actually documents that though.
(Although there is a good description of hi res timers on sourceforge, and it's unambiguous, but clock clicks is IMPLEMENTATION DEPENDENT, and thus any docs there possibly aren't much use).
Fa
TIA
Hamish.
7 Replies
HamishAnd it doesn't implement the [clock milliseconds] option which is the preferred method and returns the time from epoch..
I ask because at the moment I'm finding the [clock clicks -milliseconds] apparently jumps backwards... Some hard docs would be useful here...
tsoi_94459Nimbostratus
Any fix for this?
hoolioCirrostratus
Tsoi,
I'm not sure there is an issue to fix. Can you clarify what problem you've encountered? If you have found a potential bug, a support case might be a better way to approach it.
Aaron- tsoi_94459fixed!
set ts [clock clicks -milliseconds] overflows
fortunately, that is not how you get the unix time, this is:
set ts [clock seconds] 
Hexum_117235Greetings!
The problem is actual!
I try to generate rfc3339 compliant timestamp with millisecond precision. My TCL script produces expected result, while iRule with same code doesn't work correct.
BEGIN
set ::TIMEZONE "+4:00"
proc mstime {} {
set ms_since_epoch [clock milliseconds]; TCL 8.5+, don't supported by BIG-IP
set ms_since_epoch [clock clicks -milliseconds]; obsoleted version of command, which only available on BIG-IP
set msl [string length ${ms_since_epoch}]; calculate amount of ciphers
set seconds [string range ${ms_since_epoch} 0 [expr $msl - 4]]
set ms [string range ${ms_since_epoch} [expr $msl - 3] $msl]
set http_request_timestamp [clock format $seconds -format %Y-%m-%dT%k:%M:%S.${ms}${::TIMEZONE}]
}
puts [mstime]
END
Some extra examples:
Code: log "seconds after epoch: [clock seconds]"
Generated message: seconds after epoch: 1365594840
Code: log "milliseconds after epoch: [clock clicks -milliseconds]"
Generated message: milliseconds after epoch: -204759372
My TCL interpreter don't produce negative number by executing command [clock clicks -milliseconds]
I expect such behavior while iRule execution.
PS: do you know when custom procedures could be defined in iRules?
m_137079I know this is a four year old thread but was wondering if anyone found solution for the overflow of [clock clicks -milliseconds] . We use 10.2 Version. Any insight is much appreciated
- MegaZone
SIRT
I worked a case on this back in 2012 and I just dug it up to cut & paste my findings:
---START---
Furthermore, with everything 64-bit in v11 already it looks like ‘clock clicks –milliseconds’ already does what you want. So if you use v11, you have it now with no wait and no workaround.
And yet more, there is a work around to get a millisecond timestamp:
set secs [expr {wide([clock seconds])}]
set msecs [expr {($secs * 1000) + ([clock clicks -milliseconds] % 1000)}]
That should avoid the rollover issue.
Basically ‘clock clicks –milliseconds’ returns a 64-bit value, but it is being truncated – we’re only returning the rightmost 32-bits. That’s why it doesn’t look anything like 1000 * seconds. But it is the accurate 32-bit ‘tail’. So if we shift seconds to the left ( * 1000) and then add the remainder from the milliseconds (% 1000) then you should be able to recreate the accurate millisecond timestamp.
‘clock clicks –milliseconds’ is a synonym for ‘clock milliseconds’ – when the whole value is present. It is the truncation on v10 that is munging the results.
For now I’d use that work around in v10 to get milliseconds.
---END---
