Using mktime to convert date to seconds since epoch - omittingelements from the tuple?

[Victor Hooi]

Hi,

I'm using pysvn to checkout a specific revision based on date - pysvn will only accept a date in terms of seconds since the epoch.

I'm attempting to use time.mktime() to convert a date (e.g. "2012-02-01) to seconds since epoch.

According to the docs, mktime expects a 9-element tuple.

My question is, how should I omit elements from this tuple? And what is the expected behaviour when I do that?

For example, (zero-index), element 6 is the day of the week, and element 7 is the day in the year, out of 366 - if I specify the earlier elements, then I shouldn't really need to specify these.

However, the docs don't seem to talk much about this.

I just tried testing putting garbage numbers for element 6 and 7, whilst specifying the earlier elements:

time.mktime((2012, 5, 5, 23, 59, 59, 23424234, 5234234 ,0 ))

It seems to have no effect what numbers I set 6 and 7 to - is that because the earlier elements are set?

How should I properly omit them? Is this all documented somewhere? What is the minimum I need to specify? And what happens to the fields I don't specify?

Cheers,
Victor

 

[Vlastimil Brom]

Hi,

I'm using pysvn to checkout a specific revision based on date - pysvn will only accept a date in terms of seconds since the epoch.

I'm attempting to use time.mktime() to convert a date (e.g. "2012-02-01) to seconds since epoch.

According to the docs, mktime expects a 9-element tuple.

My question is, how should I omit elements from this tuple? And what is the expected behaviour when I do that?

For example, (zero-index), element 6 is the day of the week, and element 7 is the day in the year, out of 366 - if I specify the earlier elements, then I shouldn't really need to specify these.

However, the docs don't seem to talk much about this.

I just tried testing putting garbage numbers for element 6 and 7, whilst specifying the earlier elements:


It seems to have no effect what numbers I set 6 and 7 to - is that because the earlier elements are set?

How should I properly omit them? Is this all documented somewhere? What is the minimum I need to specify? And what happens to the fields I don't specify?

Cheers,
Victor

Hi,
if you initially have the time information as string, you might use
time.strptime(...) to extract this based on the supplied format; the
output of this function is usable as input for mktime, the remaining
fields are presumably handled consistently.
see:
http://docs.python.org/2/library/time.html#time.strftime
time.struct_time(tm_year=2012, tm_mon=3, tm_mday=17, tm_hour=0,
tm_min=0, tm_sec=0, tm_wday=5, tm_yday=77, tm_isdst=-1)
hth,
vbr

 

[Dave Angel]

Hi,

I'm using pysvn to checkout a specific revision based on date - pysvn will only accept a date in terms of seconds since the epoch.

I'm attempting to use time.mktime() to convert a date (e.g. "2012-02-01) to seconds since epoch.

According to the docs, mktime expects a 9-element tuple.

Actually, it expects a struct_time, but will work with a tuple. The
easiest way to build a struct_time from your string would be using

time.strptime(), as suggested by Vlastimil.

<snip>

The other problem is one of timezone. I would assume that svn would be
expecting all times to be in UTC, so to convert from struct_time in UTC
to seconds since epoch, you'd use calendar.timegm()
<http://docs.python.org/2/library/calendar.html#calendar.timegm> See
the chart on http://docs.python.org/2/library/time

 

[Roy Smith]

Hi,

I'm using pysvn to checkout a specific revision based on date - pysvn will
only accept a date in terms of seconds since the epoch.

I'm attempting to use time.mktime() to convert a date (e.g. "2012-02-01) to
seconds since epoch.

In what timezone is "2012-02-01" supposed to be interpreted? You really
can't do anything without knowing that.

According to the docs, mktime expects a 9-element tuple.

Over the past couple of years, I have slowly come to embrace the Python
datetime class. It makes all of this stuff so much easier.

The one thing it's missing is the ability to parse date strings in a
sane way (I don't consider strptime() to be sane). Installing dateutil
(http://labix.org/python-dateutil) is de rigueur, if for no reason other
than to get dateutil.parser.parse(). Once you've got that (and assuming
your 2012-03-01 is in UTC)
1331942400.0

I never want to see another timetuple again.

PS: you need Python 2.7 to get total_seconds(). But, then again, I
consider Python 2.7 to be de rigueur as well.

PPS: Some additional hints for staying sane while working with dates:

1) Do everything in UTC.

2) Even if you violate rule #1 at the edges, always, without exception,
store dates in your database (and transmit them over your APIs) in UTC.

3) Run all your servers with their timezones set to UTC.

4) Run NTP everywhere.

5) If in doubt, see rule #2.

6) If it's absolutely impossible to obey rule #2, at least store and
transmit time in a self-describing format (i.e. one which includes the
timezone information).

7) If it's absolutely impossible to obey rule #6, run away from the
project.

 

[Chris Angelico]

PPS: Some additional hints for staying sane while working with dates:

I assume you mean timestamps. A date doesn't need to worry about UTC
the way a timestamp does. Beyond that, I agree with most of your
comments.

3) Run all your servers with their timezones set to UTC.

Not strictly necessary imo; as long as your application knows that it
needs to work in UTC, it doesn't matter what the OS works in. But yes,
it is a convenience.

7) If it's absolutely impossible to obey rule #6, run away from the
project.

Absolutely.

ChrisA

 

[Roy Smith]

I assume you mean timestamps. A date doesn't need to worry about UTC
the way a timestamp does.

[/QUOTE]

I'm not sure how a date and a timestamp differ in any significant
way. A date is just a very low-precision time.

Not strictly necessary imo; as long as your application knows that it
needs to work in UTC, it doesn't matter what the OS works in. But yes,
it is a convenience.

Many small conveniences add up to conservation of sanity

I suppose what's really essential is a way to quickly see the current
UTC time. That way, when you're looking at some event in a log file,
it's easy to figure out, "that was 20 minutes ago", as opposed to,
"that was 5 hours and 20 minutes ago". I run my desktop in New York
time (so I know when I'm supposed to eat lunch), but I also have a
second clock widget displaying UTC time just below it. Right now,
it's 17:22.

 

[Chris Angelico]

I'm not sure how a date and a timestamp differ in any significant
way. A date is just a very low-precision time.

I suppose what's really essential is a way to quickly see the current
UTC time. That way, when you're looking at some event in a log file,
it's easy to figure out, "that was 20 minutes ago", as opposed to,
"that was 5 hours and 20 minutes ago". I run my desktop in New York
time (so I know when I'm supposed to eat lunch), but I also have a
second clock widget displaying UTC time just below it. Right now,
it's 17:22.[/QUOTE]

The difference between "20 minutes ago" and "5 hours and 20 minutes
ago" doesn't really come up when your resolution is 86400 seconds, as
is the case with a date

I have the same sort of thing. My desktop's clock is on local time
(4:33AM), but my server tells me, when I type 'who', that "The current
UTC (GMT) time is: Wed 17:33:35" (it doesn't bother with the date,
only the day of week, as the main purpose of that time display is to
help people synchronize on weekly events).

ChrisA

 

[Dave Angel]

The difference between "20 minutes ago" and "5 hours and 20 minutes
ago" doesn't really come up when your resolution is 86400 seconds, as
is the case with a date

Only 20.83 % of the time for that timezone. You might not notice it if
you always log off by 7pm.

 

[Barry Scott]

Hi,

I'm using pysvn to checkout a specific revision based on date - pysvn will only accept a date in terms of seconds since the epoch.

I'm attempting to use time.mktime() to convert a date (e.g. "2012-02-01) to seconds since epoch.

According to the docs, mktime expects a 9-element tuple.

My question is, how should I omit elements from this tuple? And what is the expected behaviour when I do that?

For example, (zero-index), element 6 is the day of the week, and element 7 is the day in the year, out of 366 - if I specify the earlier elements, then I shouldn't really need to specify these.

However, the docs don't seem to talk much about this.

I just tried testing putting garbage numbers for element 6 and 7, whilst specifying the earlier elements:


It seems to have no effect what numbers I set 6 and 7 to - is that because the earlier elements are set?

How should I properly omit them? Is this all documented somewhere? What is the minimum I need to specify? And what happens to the fields I don't specify?

See the python docs the tuple is fully documented.
6 and 7 are not needed to figure out the seconds so are ignored.

Did you notice the parse_datetime.py that is in the pysvn Client Example? Its a rather
over the top date and time parser I wrote a long long time ago. (Which is missing some imports,
hmm I cannot have tested this for a long time). It can parse things like "yesterday 10:34".

Barry