Re: Best practise for passing time as arguments

2017-10-14 Thread Christopher Reimer 
On Oct 14, 2017, at 10:44 AM, Thomas Jollans  wrote:
> 
>> On 14/10/17 19:34, Stefan Ram wrote:
>> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>>> a post. Use whatever is appropriate in the special case
>>> given, or - to write a general library -, learn the design
>>> of a good existing library, like Time4J, first.
>> 
>>  Though in many cases, an ISO 8601 time string 
>>  represented by a (named )Python tuple should
>>  be sufficient for a time stamp.
>> 
>>  E.g., ( year, month, day, hour, minute, seconds,
>>  zone_offset ).
>> 
> 
> Python provides a datetime (also: date, time, timedelta) type. Use it.
> 
> https://docs.python.org/3/library/datetime.html
> 
> When working with time zones, the standard library needs a little help.
> Luckily, there's a module for that. https://pypi.python.org/pypi/pytz
> 
> -- Thomas
> -- 
> https://mail.python.org/mailman/listinfo/python-list

I wrote a blog post about muddling through the timestamp problem, showing 
examples for datetime, slice-and-dice text, and pytz. Since I was dealing with 
time zone-specific timestamps, I went with pytz in the end.

https://www.kickingthebitbucket.com/2017/04/04/the-python-time-zone-rabbit-hole/

Chris R.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best practise for passing time as arguments

2017-10-14 Thread Chris Angelico 
On Sun, Oct 15, 2017 at 8:15 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> * You get into the habit of posting distro-specific (not just
>> OS-specific) commands to global mailing lists.
>
> And? I don't mind you posting the instructions for any other Linux
> distro. Chances are the translation into my distro is somewhat obvious.
> At least it would encourage me to find out.
>
> In no way would I be annoyed by equivalent instructions for alternative
> operating systems such as OSX or Windows (assuming Python and the
> relevant packages are available on those operating systems, which I have
> no knowledge of).

Or, you could just post a link to PyPI, which applies to all platforms
at once, and let people work out their own platform-specific
alternatives for themselves. Oh hey, that's what Thomas already did.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best practise for passing time as arguments

2017-10-14 Thread Marko Rauhamaa 
Chris Angelico :

> * You get into the habit of posting distro-specific (not just
> OS-specific) commands to global mailing lists.

And? I don't mind you posting the instructions for any other Linux
distro. Chances are the translation into my distro is somewhat obvious.
At least it would encourage me to find out.

In no way would I be annoyed by equivalent instructions for alternative
operating systems such as OSX or Windows (assuming Python and the
relevant packages are available on those operating systems, which I have
no knowledge of).


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best practise for passing time as arguments

2017-10-14 Thread Chris Angelico 
On Sun, Oct 15, 2017 at 7:57 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> On Sun, Oct 15, 2017 at 5:20 AM, Marko Rauhamaa  wrote:
>>> Even better:
>>>
>>>sudo dnf install python3-pytz
>>
>> How is that better? It's the same thing, packaged differently, and
>> thus only available on Red Hat-family systems, and depends on the
>> update cycle of your OS.
>
> Use the native updater your distro.
>
> Several nice things follow from the OS packaging:
>
>  * You don't have to have *two* separate security update/bug fix
>streams. Once you've added pytz to your OS package collection, you'll
>get updates with the routine OS updates.
>
>  * You have the benefit of a major outside entity vetting your packages.
>PyPI doesn't have any such oversight: https://arstechnica.com/in
>formation-technology/2017/09/devs-unknowingly-use-malicious-modules-pu
>t-into-official-python-repository/>.
>
>(Of course, one shouldn't overestimate the security of
>volunteer-maintained distros, either, but PyPI allows anybody to
>submit any junk they want.)
>
>  * If you want to release your software to others, your third-party
>dependency statement becomes more concise and possible more
>acceptable to your customer. Also, you don't have to ship the
>third-party package yourself.
>
>Your customer likely knows how to update native distro packages, but
>may not be familiar with Python and its ecosystem. Depending only on
>the distro relieves you from educating your customer about PyPI.

* You get into the habit of posting distro-specific (not just
OS-specific) commands to global mailing lists.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best practise for passing time as arguments

2017-10-14 Thread Marko Rauhamaa 
Chris Angelico :

> On Sun, Oct 15, 2017 at 5:20 AM, Marko Rauhamaa  wrote:
>> Even better:
>>
>>sudo dnf install python3-pytz
>
> How is that better? It's the same thing, packaged differently, and
> thus only available on Red Hat-family systems, and depends on the
> update cycle of your OS.

Use the native updater your distro.

Several nice things follow from the OS packaging:

 * You don't have to have *two* separate security update/bug fix
   streams. Once you've added pytz to your OS package collection, you'll
   get updates with the routine OS updates.

 * You have the benefit of a major outside entity vetting your packages.
   PyPI doesn't have any such oversight: https://arstechnica.com/in
   formation-technology/2017/09/devs-unknowingly-use-malicious-modules-pu
   t-into-official-python-repository/>.

   (Of course, one shouldn't overestimate the security of
   volunteer-maintained distros, either, but PyPI allows anybody to
   submit any junk they want.)

 * If you want to release your software to others, your third-party
   dependency statement becomes more concise and possible more
   acceptable to your customer. Also, you don't have to ship the
   third-party package yourself.

   Your customer likely knows how to update native distro packages, but
   may not be familiar with Python and its ecosystem. Depending only on
   the distro relieves you from educating your customer about PyPI.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best practise for passing time as arguments

2017-10-14 Thread Chris Angelico 
On Sun, Oct 15, 2017 at 5:20 AM, Marko Rauhamaa  wrote:
> Thomas Jollans :
>
>> When working with time zones, the standard library needs a little help.
>> Luckily, there's a module for that. https://pypi.python.org/pypi/pytz
>
> Even better:
>
>sudo dnf install python3-pytz

How is that better? It's the same thing, packaged differently, and
thus only available on Red Hat-family systems, and depends on the
update cycle of your OS.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best practise for passing time as arguments

2017-10-14 Thread Marko Rauhamaa 
Thomas Jollans :

> When working with time zones, the standard library needs a little help.
> Luckily, there's a module for that. https://pypi.python.org/pypi/pytz

Even better:

   sudo dnf install python3-pytz


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best practise for passing time as arguments

2017-10-14 Thread Marko Rauhamaa 
r...@zedat.fu-berlin.de (Stefan Ram):

>   Of course, you (the OP), should check out
>
> datetime.datetime
>
>   and
>
> datetime.timedelta
>
>   from the Python Library.

which he mentioned in his post.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best practise for passing time as arguments

2017-10-14 Thread Thomas Jollans 
On 14/10/17 19:34, Stefan Ram wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> a post. Use whatever is appropriate in the special case
>> given, or - to write a general library -, learn the design
>> of a good existing library, like Time4J, first.
> 
>   Though in many cases, an ISO 8601 time string 
>   represented by a (named )Python tuple should
>   be sufficient for a time stamp.
> 
>   E.g., ( year, month, day, hour, minute, seconds,
>   zone_offset ).
> 

Python provides a datetime (also: date, time, timedelta) type. Use it.

https://docs.python.org/3/library/datetime.html

When working with time zones, the standard library needs a little help.
Luckily, there's a module for that. https://pypi.python.org/pypi/pytz

-- Thomas
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best practise for passing time as arguments

2017-10-14 Thread Marko Rauhamaa 
Andrew Z :

>  I wonder what are the "best practises" for passing "time" parameters to
> functions?
> I noticed that sometimes i pass "time" as a str and then start "massaging"
> it into delta or i need this time format or that format. Thats quite
> annoying and inconsistent.

I do the same thing. It's not all that bad because the choice depends on
the needs of the application.

It's a slight bit annoying that I have to write parsing functions
myself, but it's not all that bad:

   def parse_date(date):
   return datetime.date(*map(int, date.split("-")))

   def parse_time(time):
   return datetime.time(*map(int, time.split(":")))

where "date" is expressed as "2017-10-14" and "time" [of day] as "19:39".


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Best practise for passing time as arguments

2017-10-14 Thread Andrew Z 
Hello,
 I wonder what are the "best practises" for passing "time" parameters to
functions?
I noticed that sometimes i pass "time" as a str and then start "massaging"
it into delta or i need this time format or that format. Thats quite
annoying and inconsistent.
I use word "time" as a general word for date/time/timedelta types.

Appreciate.
-- 
https://mail.python.org/mailman/listinfo/python-list