Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #35966 > unrolled thread

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

Back to article view | Back to comp.lang.python

Contents

  Using mktime to convert date to seconds since epoch - omitting elements from the tuple? Victor Hooi <victorhooi@gmail.com> - 2013-01-02 00:01 -0800
    Re: Using mktime to convert date to seconds since epoch - omitting elements from the tuple? Vlastimil Brom <vlastimil.brom@gmail.com> - 2013-01-02 09:33 +0100
    Re: Using mktime to convert date to seconds since epoch - omitting elements from the tuple? Dave Angel <davea@dejaviewphoto.com> - 2013-01-02 09:06 -0500
    Re: Using mktime to convert date to seconds since epoch - omitting elements from the tuple? Roy Smith <roy@panix.com> - 2013-01-02 09:28 -0500
      Re: Using mktime to convert date to seconds since epoch - omitting elements from the tuple? Chris Angelico <rosuav@gmail.com> - 2013-01-03 01:51 +1100
        Re: Using mktime to convert date to seconds since epoch - omitting elements from the tuple? roy@panix.com (Roy Smith) - 2013-01-02 12:27 -0500
          Re: Using mktime to convert date to seconds since epoch - omitting elements from the tuple? Chris Angelico <rosuav@gmail.com> - 2013-01-03 04:34 +1100
          Re: Using mktime to convert date to seconds since epoch - omitting elements from the tuple? Dave Angel <d@davea.name> - 2013-01-02 12:44 -0500
    Re: Using mktime to convert date to seconds since epoch - omitting elements from the tuple? Barry Scott <barry@barrys-emacs.org> - 2013-01-03 23:46 +0000

#35966 — Using mktime to convert date to seconds since epoch - omitting elements from the tuple?

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

[toc] | [next] | [standalone]

#35967

2013/1/2 Victor Hooi <victorhooi@gmail.com>:
> 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
> --
> http://mail.python.org/mailman/listinfo/python-list

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.strptime("2012-3-17", "%Y-%m-%d")
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)
>>> time.mktime(time.strptime("2012-3-17", "%Y-%m-%d"))
1331938800.0
>>>

hth,
   vbr

[toc] | [prev] | [next] | [standalone]

#35983

On 01/02/2013 03:01 AM, Victor Hooi wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#35992

In article <dfd18cf3-e2c0-4f0e-a4c1-a72924039a15@googlegroups.com>,
 Victor Hooi <victorhooi@gmail.com> wrote:

> 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)

>>> epoch = parse("1970-01-01T00:00:00+0000")
>>> t = parse("2012-03-17T00:00:00+0000")
>>> (t - epoch).total_seconds()
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.

[toc] | [prev] | [next] | [standalone]

#35996

On Thu, Jan 3, 2013 at 1:28 AM, Roy Smith <roy@panix.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#35998

In article <mailman.1574.1357138278.29569.python-list@python.org>,
Chris Angelico  <rosuav@gmail.com> wrote:

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

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

>> 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.

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.

[toc] | [prev] | [next] | [standalone]

#35999

On Thu, Jan 3, 2013 at 4:27 AM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.1574.1357138278.29569.python-list@python.org>,
> Chris Angelico  <rosuav@gmail.com> wrote:
>
>>> I assume you mean timestamps. A date doesn't need to worry about UTC
>>> the way a timestamp does.
>
> 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.

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

[toc] | [prev] | [next] | [standalone]

#36000

On 01/02/2013 12:34 PM, Chris Angelico wrote:
> On Thu, Jan 3, 2013 at 4:27 AM, Roy Smith <roy@panix.com> wrote:
>> In article <mailman.1574.1357138278.29569.python-list@python.org>,
>> Chris Angelico  <rosuav@gmail.com> wrote:
>>
>>>> I assume you mean timestamps. A date doesn't need to worry about UTC
>>>> the way a timestamp does.
>> 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.
> 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.

>
> 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


-- 

DaveA

[toc] | [prev] | [next] | [standalone]

#36091

On 2 Jan 2013, at 08:01, Victor Hooi <victorhooi@gmail.com> wrote:

> 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?

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web