• Views
  • Iteration Report
  • My Iteration Report
  •  
OMERO.server
  • Login
  • Help/Guide
  • About Trac
  • Preferences
  • Wiki
  • Timeline
  • Roadmap
  • Browse Source
  • View Tickets
  • Search

Context Navigation

  • ← Previous Ticket
  • Next Ticket →

Ticket #1053 (closed defect: fixed)

Opened 4 months ago

Last modified 3 months ago

Session.timeToLive representation does not work in Python

Reported by: jmoore Owned by: jmoore
Priority: minor Milestone: 3.0-Beta3.1
Component: General Version:
Keywords: Cc: callan, atarkowska, cblackburn

Description

Currently timeToLive represents the number of milliseconds after session creation (started, in milliseconds since the epoch) which a session can still be accessed, or:

  if (currentTime > sessionCreation + timeToLive) {
     removeSession();
  }

Currently, sessions (specifically OmeroShares) which are to persist forever, are given a value of:

   Long.MAX_VALUE - sessionCreation

so that:

        long time = System.currentTimeMillis();
        long max = Long.MAX_VALUE;
        System.out.println(max - time);
        System.out.println(new Timestamp(max - time));

produces

9223370818800686547
292278956-01-11 11:51:26.547

When this value is transported to other systems, like python, the time libraries are unhappy:

time.ctime(creationTime/1000+t )
timestamp out of range for platform time_t

making display difficult.

Change History

Changed 4 months ago by jmoore

I'd prefer not to use a negative value to represent "the end of time", since doing math on that can make for very strange results. It would be an option to choose as the maximum value 2038 (the maximum value in Python), but I *hope* OMERO actually runs that long. Would it be possible, Ola, to catch the ValueError and simply display: "No expiration"?

Changed 3 months ago by jmoore

Ola, what are your thoughts on this?

Changed 3 months ago by cblackburn

Is it feasible to use a third-party library such as,

http://www.egenix.com/products/python/mxBase/mxDateTime/

Changed 3 months ago by jmoore

  • cc cblackburn added
  • status changed from new to closed
  • resolution set to fixed

Colin, thanks for the link. The mx library looks interesting; in addition to the date/time bits, mxBeeBase and mxUID among others could be useful. Do you think this is something we should package? Have you used it in anger?

Anyway, I think for the moment we'll consider the server's definition of timeToLive (even if it should be in seconds and not milliseconds) definitive and find a way to work around in the other languages. If this proves impossible, we can re-evaluate.

Changed 3 months ago by callan

  • version deleted

FWIW, I use mx extensively in my side projects. It's particularly nice for working with date's and time's and is a stable, well documented and well written library.

Changed 3 months ago by jmoore

Good to hear. The major problem would be the native code. But I think that's going to be something we have to tackle one way or the other.

Note: See TracTickets for help on using tickets.

Download in other formats:

  • Comma-delimited Text
  • Tab-delimited Text
  • RSS Feed

Trac Powered

Powered by Trac 0.11
By Edgewall Software.

Visit the Trac open source project at
http://trac.edgewall.org/