I've a new_git_repository containing:
new_git_repository(
name = "hyperscan",
build_file = "//external-deps/hyperscan:BUILD",
commit = "[COMMIT_HASH]",
remote = "https://github.com/intel/hyperscan.git",
shallow_since = "2018-07-09",
)
When building it says:
DEBUG: Rule 'hyperscan' indicated that a canonical reproducible form can be obtained by modifying arguments shallow_since = "1531154744 -0400"
According to this, shouldn't the shallow_since format be of YYYY-MM-DD?
And next, what does shallow_since = "1531154744 -0400" mean?!
Bazel does not process the string specified as shallow_since attribute and passes it directly to git as --shallow-since parameter. It can be seen in Bazel source code here.
The value you see is Git internal date format which is <unix timestamp> <time zone offset>, where <unix timestamp> is the number of seconds since the UNIX epoch. <time zone offset> is a positive or negative offset from UTC. For example CET (which is 1 hour ahead of UTC) is +0100.
Here is the tool for unix timestamp conversion to the human-readable date/time and back.
Bazel uses git log --date=raw to get the timestamp of the commit, and then does a string comparison with the value of shallow_since. In my opinion, it is a bug in Bazel - it should do a date comparison instead.
As specified in the comments, you can use git log --date=raw to get the commit sha and the time (shallow_since) of the desired commit.
Related
One can use bjobs to get the start time of an LSF job as such:
bjobs -noheader -o start_time $JOB
However, this returns low-fidelity (e.g., seconds are not necessarily included) human readable output. Higher (but not necessarily "full", I believe) fidelity output can be parsed out of:
bjobs -l $JOB
...but that's rather messy. Also, as I alluded to, I think the output can still be ambiguous; the year doesn't always seem to be included here and I don't recall seeing any time zone information.
How can I get an LSF job's start time deterministically and unambiguously (say, as a Unix epoch)?
IMHO the seconds are always included in start_time and the timestamp is exactly the same as the one reported by bjobs -l $JOBID.
To show the year in the date, you have to set LSB_DISPLAY_YEAR=Y in lsf.conf. This is not set by default in LSF. Don't forget to run lsadmin reconfig;badmin mbdrestart after having modified lsf.conf.
You can convert dates with date:
date --date "`bjobs -noheader -o start_time $JOBID`" +"%s"
or
date --date "$(bjobs -noheader -o start_time $JOBD)" +"%s"
if you prefer.
I need a date time string formatted as %Y-%m-%d %H:%M:%S.
I can't figure out how to use Lua's standard functions os.date() and os.time() to achieve that.
os.date is the function you are looking for. Its first optional parameter, format, does what you want:
os.date('%Y-%m-%d %H:%M:%S')
--> 2019-04-02 10:50:52
From the Lua 5.3 manual on os.date:
os.date ([format [, time]])
Returns a string or a table containing date and time, formatted according to the given string format.
If format starts with '!', then the date is formatted in Coordinated Universal Time.
If format is not "*t", then date returns the date as a string, formatted according to the same rules as the ISO C function strftime.
You can learn more about the formatting rules of C's strftime here.
In case you don't get your local time for whatever reason you can simply add the required offset.
local timeShift = 3 * 60 * 60 -- +3 hours
os.date('%Y-%m-%d %H:%M:%S', os.time() + timeShift)
--> 2019-04-02 18:24:15 for 15:24:15 UTC
I use lib https://github.com/Tieske/date. Get localtime -
date(true):addminutes("your offset"):fmt('%Y-%m-%d %H:%M:%S'),
In the Hadoop infrastructure (Java-based) I am getting timestamps as string values in this format:
2015-10-01T04:22:38:208Z
2015-10-01T04:23:35:471Z
2015-10-01T04:24:33:422Z
I tried different patters following examples for SimpleDateFormat Java class without any success.
Replaced 'T' with ' ' and 'Z' with '', then
"yyyy-MM-dd HH:mm:ss:ZZZ"
"yyyy-MM-dd HH:mm:ss:zzz"
"yyyy-MM-dd HH:mm:ss:Z"
"yyyy-MM-dd HH:mm:ss:z"
Without replacement,
"yyyy-MM-dd'T'HH:mm:ss:zzz'Z'"
In fact, this format is not listed among examples. What should I do with it?
Maybe those 3 digits are milliseconds, and time is in UTC, like this: "yyyy-MM-dd'T'HH:mm:ss.SSSZ"? But it still should look like "2015-11-27T10:50:44.000-08:00" as standardized format ISO-8601.
Maybe, this format is not parsed correctly in the first place?
I use Ruby, Python, Pig, Hive to work with it (but not Java directly), so any example helps. Thanks!
I very strongly suspect the final three digits are nothing to do with time zones, but are instead milliseconds, and yes, the Z means UTC. It's a little odd that they're using : instead of . as the separator between seconds and milliseconds, but that can happen sometimes.
In that case you want
"yyyy-MM-dd'T'HH:mm:ss:SSSX"
... or use
"yyyy-MM-dd'T'HH:mm:ss:SSS'Z'"
and set your SimpleDateFormat's time zone to UTC explicitly.
Consider this example:
package main
import (
"fmt"
"time"
)
func main() {
fmt.Println(time.Parse(time.RFC3339, time.RFC3339))
}
The output is:
0001-01-01 00:00:00 +0000 UTC parsing time "2006-01-02T15:04:05Z07:00": extra text: 07:00
Why can't time.Parse() handle a layout as a value? What's missing here?
UPDATE: Cutting off the time zone value (but not the 'Z' delimiting the time from the zone) fixes it:
fmt.Println(time.Parse(time.RFC3339, "2015-09-15T11:50:00Z"))
Why can't time.Parse() handle time zone info when using time.RFC3339 as the layout string?
http://play.golang.org/p/p3fHfJNHVK
UPDATE: JimB's answer led me to read from RFC3339 and I found these examples that clarify further:
Here are some examples of Internet date/time format.
1985-04-12T23:20:50.52Z
This represents 20 minutes and 50.52 seconds after the 23rd hour of
April 12th, 1985 in UTC.
1996-12-19T16:39:57-08:00
This represents 39 minutes and 57 seconds after the 16th hour of
December 19th, 1996 with an offset of -08:00 from UTC (Pacific
Standard Time). Note that this is equivalent to 1996-12-20T00:39:57Z
in UTC.
The time.RFC3339 format is a case where the format string itself isn't a valid time. You can't have a Z and an offset in the time string, but the format string has both because the spec can contain either type of timezone specification.
Both of these are valid RFC3339 times:
"2015-09-15T14:00:12-00:00"
"2015-09-15T14:00:13Z"
And the time package needs to be able to parse them both using the same RFC3339 format string.
As noted, 2006-01-02T15:04:05Z07:00 is an invalid IETF RFC-3339 time format. Here's an explanation.
The reason you cannot have both Z and an offset is that they are both ways to represent a time offset. Z is equivalent to +00:00 indicating a zero hour/minute offset, or no offset. You cannot say both +00:00 offset and +07:00 offset in the same time representation.
The following is the Z definition in the RFC-3339 Section 2:
https://www.rfc-editor.org/rfc/rfc3339#section-2
Z A suffix which, when applied to a time, denotes a UTC
offset of 00:00; often spoken "Zulu" from the ICAO
phonetic alphabet representation of the letter "Z".
Of note, while Z is equivalent to +00:00, they are both different from -00:00 which indicates known UTC time with an unknown offset, as described in RFC-3339 Section 4.3:
https://www.rfc-editor.org/rfc/rfc3339#section-4.3
4.3. Unknown Local Offset Convention
If the time in UTC is known, but the offset to local time is unknown,
this can be represented with an offset of "-00:00". This differs
semantically from an offset of "Z" or "+00:00", which imply that UTC
is the preferred reference point for the specified time. RFC2822
[IMAIL-UPDATE] describes a similar convention for email.
How can I parse a time string, such as Sun May 27 13:02:04 +0200 2012, to a tuple in UTC, using python3? The closest I can get is time.strptime(str, '%a %b %d %H:%M:%S %z %Y'), but it seems the offset is parsed but ignored. The above example is parsed to:
time.struct_time(tm_year=2012, tm_mon=5, tm_mday=27, tm_hour=13, tm_min=1, tm_sec=35, tm_wday=6, tm_yday=148, tm_isdst=-1)
but I expected tm_hour=11.
Related: Convert string timestamp (with timezone offset) to local time. . ? python, Parsing time string in Python. Answers to both suggests the use of dateutil, but I'd prefer using the standard library, if possible.
tm_hour=11 would be incorrect. The time in the timestamp is 13:02:04, no matter what the offset is.
What you want to do is to convert that timestamp into a time in GMT, which the standard library won't do for you. So you will just have to extract the offset yourself (which is trivial) and then subtract it from the time.
I'd also recommend you to use the datetime library for this, date/time manipulation is much easier there, you can easily create a timedelta object from the offset and subtract that from the datetime object.