Issue with minor version of CURRENT_VERSION_ID

[mdxs]

According to https://developers.google.com/appengine/docs/python/#Python_The_environment the minor version of CURRENT_VERSION_ID is always "1" on the development web server.

However, I'm seeing stuff like 423594672088649939 using version 1.8.9 of the SDK (on a Xubuntu virtual machine), which I'm afraid sometimes triggers an exception in config.py when converting to long in the CURRENT_VERSION_TIMESTAMP; and/or resulting in CURRENT_VERSION_DATE being way out in the past or the future (that is: on the development web server).

Is this something in my development VM, or are others also seeing the CURRENT_VERSION_ID.split('.')[1] unequal to "1" on their local development web server testing (using SDK 1.8.9)?

[lipis]

I think they forgot to update the docs.. it was a bad idea to have it always 1 because you are usually using that for cache forever in the scripts or stylesheets as a query argument to make sure you're getting the updated one..

but it also not showing the current date or anything but something that it looks like random so in general it's not a problem for the dev environment..

in the issue #63 Jörn also wanted to fix it but it's not worth it if you ask me..

[mdxs]

Filled upstream as documentation issue; see https://code.google.com/p/googleappengine/issues/detail?id=10601

For gae-init, the problem seems to be that the random (?) number provided by the current implementation might not fit in the long that the CURRENT_VERSION_TIMESTAMP = long(CURRENT_VERSION_ID.split('.')[1]) >> 28 assignment is using; thus causing sometimes (I think... didn't test sufficiently yet) an exception which might leave some (later) assignments undefined... I'm not sure if there are any major negative outcomes (read: crashes) due to this, but it does provide some weird output on the development server... which might put some wannabee users off (because... if it doesn't work locally, why risk deploying?).

[lipis]

The long in Python can be pretty long and basically there is no limit on what it can fit, the only problem with the local version is that the date is not accurate and it shows most of the time the future as addressed in the #63 as far as I can tell.. other than that I don't think that this can cause any other problems..

as for the misleading date or something.. we could probably document it..

[mdxs]

Should have caught it before... the error is a "timestamp out of range for platform time_t"

[mdxs]

When there is no exception caught I'm seeing (as admin) 1985, 2004, 2010, 2016 (future), 2003, 1972, etc based timestamps on the hello page.

When there has been an exception, it shows "a few seconds ago" and "Invalid date" on hoover over, looking at page source, the datetime="" on the time tag.

By dumping some more config values in the footer, it is also clear that when there is an exception that the new config.APPLICATION_ID is skipped and thus blank. Now, this can be worked around (just change the order), but I do like (part of) the @joernhees approach better:

# ... move the SERVER_SOFTWARE, DEVELOPMENT and friends stuff before the try

try:
  ...
  CURRENT_VERSION_NAME = CURRENT_VERSION_ID.split('.')[0]
  CURRENT_VERSION_TIMESTAMP = long(CURRENT_VERSION_ID.split('.')[1]) >> 28
  if DEVELOPMENT:
    CURRENT_VERSION_TIMESTAMP = long(datetime.now())
  CURRENT_VERSION_DATE = datetime.fromtimestamp(CURRENT_VERSION_TIMESTAMP)
  ...

[mdxs]

Hmm, above snippet doesn't cut it...