Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
C
cpython
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Kirill Smelkov
cpython
Commits
6d46dff5
Commit
6d46dff5
authored
Sep 10, 2014
by
Benjamin Peterson
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
y2k compliance, lol (closes #22380)
parent
14867998
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
0 additions
and
37 deletions
+0
-37
Doc/faq/general.rst
Doc/faq/general.rst
+0
-37
No files found.
Doc/faq/general.rst
View file @
6d46dff5
...
@@ -377,43 +377,6 @@ Providing a gradual upgrade path is necessary if a feature has to be changed.
...
@@ -377,43 +377,6 @@ Providing a gradual upgrade path is necessary if a feature has to be changed.
changes while minimizing disruption for users.
changes while minimizing disruption for users.
Is Python Y2K (Year 2000) Compliant?
------------------------------------
.. remove this question?
As of August, 2003 no major problems have been reported and Y2K compliance seems
to be a non-issue.
Python does very few date calculations and for those it does perform relies on
the C library functions. Python generally represents times either as seconds
since 1970 or as a ``(year, month, day, ...)`` tuple where the year is expressed
with four digits, which makes Y2K bugs unlikely. So as long as your C library
is okay, Python should be okay. Of course, it's possible that a particular
application written in Python makes assumptions about 2-digit years.
Because Python is available free of charge, there are no absolute guarantees.
If there *are* unforeseen problems, liability is the user's problem rather than
the developers', and there is nobody you can sue for damages. The Python
copyright notice contains the following disclaimer:
4. PSF is making Python 2.3 available to Licensee on an "AS IS"
basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY
WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND DISCLAIMS ANY
REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR
PURPOSE OR THAT THE USE OF PYTHON 2.3 WILL NOT INFRINGE ANY THIRD PARTY
RIGHTS.
5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON
2.3 FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS
A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON 2.3,
OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.
The good news is that *if* you encounter a problem, you have full source
available to track it down and fix it. This is one advantage of an open source
programming environment.
Is Python a good language for beginning programmers?
Is Python a good language for beginning programmers?
----------------------------------------------------
----------------------------------------------------
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment