Get Unix timestamp (in seconds) for a hg commit

unix timestamp milliseconds
hg log
hg update
hg commit message
hg pull
hg push
hg update to revision
hg diff

Given a commit with the date Mon Aug 18 21:05:38 2014 +0200, how can I get the Unix timestamp of it in seconds?

The following command produces a number that discards the number (presumably because the timezone information of date got discarded):

$ hg log -l1 --template '{date(date, "%s")}\n'
1408392338
$ date -d@1408392338
Mon Aug 18 22:05:38 CEST 2014

I am effectively looking for the equivalent of the git command that produces the commit date as a Unix timestamp:

git log -n1 --pretty=%ct

The requested timestamp was one that is independent of the timezone, so UTC time. As date(..., "%s") produces a number which is relative to the current timezone, one should request a UTC output by combining the localdate filter with the TZ environment variable to set a timezone:

TZ=UTC hg log -l1 --template '{date(date|localdate, "%s")}\n')

Mercurial timestamp on commit, how to record datecode as commit , In order to get versioning on these files finally right, I thought about When you do a hg commit --help, mercurial will give you these options on commits: The first number is a Unix UTC timestamp (seconds since January 1,  The date is expressed as a pair of numbers. The first number is a Unix UTC timestamp (seconds since January 1, 1970); the second is the offset of the committer’s timezone from UTC, in seconds." Update: hg help dates gives a list of valid date formats. So, a commit with these options: hg commit -d '1135425600 0' -m "commit on 2005-12-24T12:00:00"

The simplest solution is to take the first field produced from the template format {date|hgdate}, which is already in UTC. The second field in this format just gives the timezone, and can be discarded by applying Mercurial's word function within the format specifier. Here is a test of this format against the system date command and your own (correct, but longer) answer, on Mercurial 3.7.3:

$ date +%s && hg commit -m 'ok'
1539258496
$ TZ=UTC hg log -l1 --template '{date(date|localdate, "%s")}\n'
1539258496
$ hg log -l1 -r. --template '{date|hgdate}'
1539258496 -7200
$ hg log -l1 --template '{word(0, date|hgdate)}'
1539258496

The correctness is also confirmed by the description in the hg manpage of the hgdate filter:

hgdate Date. Returns the date as a pair of numbers: "1157407993 25200" (Unix timestamp, timezone offset).

(Side note: The timezone offset, a little confusingly, is negated: I'm in UTC+2, but the offset is given as -7200 seconds. However, this is only important if you want the local time. If you're after UTC, you will be ignoring the offset in any case.)

Overall, the date|hgdate variant only saves a few characters, but personally I find it conceptually cleaner and easier to understand. It may also be a little more robust against potential future bugs in Mercurial, since it involves fewer parsing and formatting operations.

Mercurial: The Definitive Guide: The Definitive Guide, The first number is a Unix UTC timestamp (seconds since January 1, 1970); the second is the offset of the committer's timezone from UTC, in seconds. 2 Answers2. active oldest votes. 15. The resolution of Git commit/author dates is 1 second, which, as pointed out by Alexey Ten and Edward Thomson, is also the resolution of Unix timestamps. An interesting experiment that you can conduct is to. create a commit, and.

Usage of hg commit --date (mercurial) : Little Impact, where 1234567890 is the seconds since epoch and 0 is the timezone. On unix (and bash) you can conveniently use the date command to do the conversion: hg commit --date "$(date -u --date '2009-2-13 23:31:30' +'%s') 0" This way, getting the filesystem metadata into a repository representation  Use 'hg commit --close-branch' to mark this branch as closed. the diff will be against the second parent. It can be useful to review a merge. (Unix timestamp

hg, The files will be added to the repository at the next commit. After using this option, hg status -C can be used to check which files were The first number is the number of seconds since the epoch (1970-01-01 00:00 UTC). Returns the date as a pair of numbers: "1157407993 25200" (Unix timestamp, timezone offset​). make-unix-timestamp-c Purpose. Provides a simple C function that takes datetime elements (e.g. seconds, minutes, hours, date, month and year) and returns a single integer representing the number of seconds elapsed since the UNIX epoch (1/1/1970).

Customizing the output of Mercurial, You can use templates to generate specific output for a single command, or to hg log --template 'i saw a changeset: {desc}\n' i saw a changeset: Added tag v0.1 The first number is a Unix UTC timestamp (seconds since January 1, 1970);  * Convert time string to a Unix timestamp (in seconds). * Uses the pattern "yyyy-MM-dd HH:mm:ss" and will return null on failure. * @group datetime_funcs * @since 2.2.0 */ def to_timestamp (s: Column): Column = withExpr {new ParseToTimestamp (s.expr, Literal (" yyyy-MM-dd HH:mm:ss "))} /** * Convert time string to a Unix timestamp (in seconds

Unix Time Stamp, Epoch and unix timestamp converter for developers. Enter a Timestamp: Convert The unix time stamp is a way to track time as a running total of seconds. You can use Command Substitution to get the current date and time when your script is run: git commit -m "$(date +"%D %T")" Alternatively you could save date's output in a variable, e.g. if you want to capture the time the script was started at, add as the first command e.g. timestamp=$(date +"%D %T") and use it later like:

Comments
  • Why not just --template "{localdate(date,'UTC')|date}\n" ?
  • @rdb Either it did not exist at the time or I was unaware of it. Consider posting your suggestion as answer and if possible, some documentation references.
  • @Lekensteyn You're correct, it didn't exist at the time. The localdate filter was turned into a function on 2015-09-01.
  • I did try date|hgdate, but besides the odd formatting, it did not give the expected result. Apparently, the first field is the local time, so to get UTC one has to subtract (rather than add) the second field.