We need to schedule a meeting for year 2039! Now!



  • A client I'm doing system customizations for wants to set up a recurring meeting on their calendar with several people invited.  Now, this system does not support recurring meetings at all.  Period.  It was designed for short-term scheduling and recording meetings that took place in the past.

    I offer them the only option available, which I've done for other clients - I can create a thousand meetings or so; they will be scheduled for decades in advance.  At least up until 2038, because this is a 32 bit system and can't store dates beyond January 19th 2038.

    They absolutely hated this idea and wanted true recurring meetings, because, in their words, "That means in 2038, we won't have any meetings scheduled!  What will we do then!?  This meeting has to go on FOREVER!".

    Yes, TRWTF is that this system doesn't support recurring meetings and that in 2013 we are still running 32 bit "enterprise" systems that can't support relatively distant dates.

    Nevertheless, the idea that maybe by 2038 they won't even be on this system (I guarantee they won't be), that the company will have gone under, that perhaps all the people invited to this meeting will have retired or died, or that paying me to customize the system for something so idiotic rather than just waiting until 2038 to schedule another batch of meetings if they truly need to is a major waste of money doesn't mean anything to them.  The meeting must immediately be scheduled in perpetuity, until the heat death of the universe.

    26 years is just not enough.



  • You should offer to make the last meeting of 2038 a meeting to schedule more meetings.



  • @KrakenLover said:

    Nevertheless, the idea that maybe by 2038 they won't even be on this system (I guarantee they won't be)

    Woah man!  Déjà vu!




  • I have it on good authority that the Reptilians will have conquered Earth and enslaved all surviving humans by 2030--2035 at the latest--and their system of time can't be expressed using integral numbers at all.

    Tell them they have nothing to worry about. Well, except for watching their cities burn and their loved ones devoured before their very eyes.



  • @morbiuswilters said:

    I have it on good authority that the Reptilians Combine will have conquered Earth and enslaved all surviving humans by 2030--2035 at the latest--and their system of time can't be expressed using integral numbers at all.

    Tell them they have nothing to worry about. Well, except for watching their cities burn and their loved ones reproductive organs devoured before their very eyes.

    FTFY



  • @DaveK said:

    @KrakenLover said:

    Nevertheless, the idea that maybe by 2038 they won't even be on this system (I guarantee they won't be)

    Woah man!  Déjà vu!

    Yeah, I realize my statement might seem a bit short-sighted or ignorant of history at first.

    An important detail here is that this is a "cloud"-based system; the client has no control over the server, and very limited control over the software (my customizations must conform to certain rules and limitations).  This client cannot be on this system in 2038 simply because the cloud-model will not allow it. 

    In this cloud environment, there is no pause button.  They are forcibly upgraded to newer versions as they are released, so this system is in no way static nor does it have the potential to be a long-running system like is used by the banking industry, or other large corporations, where the consequences of the Y2K issue were most apparent and severe.

    Scheduling a meeting 26 years in advance in a system that is completely cloud-based seems to me a lot like planning furniture layouts of a house that's burning down.  It just doesn't make sense to treat it like it's always going to be there because it is lacking longevity by its very nature.

     



  • @KrakenLover said:

    They absolutely hated this idea and wanted true recurring meetings,

    The correct response is to agree that this is indeed a half-baked temporary workaround for a deplorable system design deficiency and assure your customer that the developer has told you personally that implementing this feature has a "high priority within the pre-2038 time frame".



  • @KrakenLover said:

    paying me to customize the system for something so idiotic
     

    Here! Here! Here!

    (Every time I say that I have seven children, and my children have five months, some lady in the audience jumps up and yells "Number Six! Number Six!".)

     



  • Reminds me of scheduling a recurring meeting with about 15 people from another organization.  Now, I sent a standard Outlook recurring invite, but apparently their system doesn't "do" recurring meetings, so it actually made about 20 years of non-recurring instances.

    And when each person accepted the invite, it sent the confirmation once for every single instance.  At random times, my email box would be obliterated by downloading almost 250 "your meeting has been accepted" emails, as another of the 15 people clicked yes.

    On the plus side, I'm happy to say that all 15 are now confirmed all the way through January of 2033.  February 2033 is still up in the air, though.

     


  • Discourse touched me in a no-no place

    @AndyCanfield said:

    Here! Here! Here!
    Where? Where? Where?



  • @KrakenLover said:

    I can create a thousand meetings or so; they will be scheduled for decades in advance.  At least up until 2038, because this is a 32 bit system and can't store dates beyond January 19th 2038.
    So what happens when your client decides that the 26 years worth of meetings scheduled for Monday morning at 9:00AM have to rescheduled to Tuesdays at 3PM because the new boss parties all weekend and never gets in before lunch on a Monday (and he can't be fired because he's the CEO's favourite nephew)?


  • Trolleybus Mechanic

    @dkf said:

    @AndyCanfield said:
    Here! Here! Here!
    Where? Where? Where?
     

    Their! Their! Their!



  • @OzPeter said:

    So what happens when your client decides that the 26 years worth of meetings scheduled for Monday morning at 9:00AM have to rescheduled to Tuesdays at 3PM because the new boss parties all weekend and never gets in before lunch on a Monday (and he can't be fired because he's the CEO's favourite nephew)?

     

    That will get overruled because the presidents daughter only works mornings.



  • @Ben L. said:

    @morbiuswilters said:
    loved ones reproductive organs

    FTFY

    Same difference, really.



  • Tell them you have written a cron job that will add more meetings, but it doesn't get kicked off right away. For example, if you carefully specify weekday, month, and day you can extend the 1st execution of the cron job until 2036.



  • @Cat said:

    Reminds me of scheduling a recurring meeting with about 15 people from another organization.  Now, I sent a standard Outlook recurring invite, but apparently their system doesn't "do" recurring meetings, so it actually made about 20 years of non-recurring instances.

     

    The real WTF is that Outlook doesn't let you cancel infinitely-recurring appointments, just delete them, so you'll lose all record of the meetings once you decide to stop having them.

     



  • @KrakenLover said:

    An important detail here is that this is a "cloud"-based system; the client has no control over the server, and very limited control over the software (my customizations must conform to certain rules and limitations).  This client cannot be on this system in 2038 simply because the cloud-model will not allow it. 

    In this cloud environment, there is no pause button.  They are forcibly upgraded to newer versions as they are released, so this system is in no way static nor does it have the potential to be a long-running system like is used by the banking industry, or other large corporations, where the consequences of the Y2K issue were most apparent and severe.

    Except of course that Raymond Chen will be busily making sure that all future OS's are bugwardly-compatible with your compromise solution for many many years into the future! :-)




  • Who actually wants these meetings in 26 years? Or, specifically, how old are they?



    You could ask them if they intend to still be employed at the company (or indeed, at all) at that time. When they inevitably say "well... no", point out that its somebody else's problem.



    If they're anal enough to say "well, I might be... who are YOU to say I wont?", then explain to them the concept of somebody else's problem, paying extra attention to the fact that

    somebody's problems can usually be transformed into somebody else's problems, and point out exactly how they can do this for their problem in this case.



  • @KrakenLover said:

    Yes, TRWTF is that this system doesn't support recurring meetings and that in 2013 we are still running 32 bit "enterprise" systems that can't support relatively distant dates.

    Indeed. Everyone should switch to RFC 2550-compliant dates.



  • @OzPeter said:

    @KrakenLover said:
    I can create a thousand meetings or so; they will be scheduled for decades in advance.  At least up until 2038, because this is a 32 bit system and can't store dates beyond January 19th 2038.
    So what happens when your client decides that the 26 years worth of meetings scheduled for Monday morning at 9:00AM have to rescheduled to Tuesdays at 3PM because the new boss parties all weekend and never gets in before lunch on a Monday (and he can't be fired because he's the CEO's favourite nephew)?
    The actual meetings are stored in MySQL, so a simple query can update all future occurrences very quickly.

    @eViLegion said:

    If they're anal enough to say "well, I might be... who are YOU to say I wont?", then explain to them the concept of somebody else's problem, paying extra attention to the fact that
    somebody's problems can usually be transformed into somebody else's problems, and point out exactly how they can do this for their problem in this case.
    Normally I'd agree with this.  But, as a consultant, more hourly work is more hourly work.  If they want to blow a couple hundred dollars an hour on this against my recommendations, then I've done my responsibility to my client and it's their prerogative to waste their own money.



  • @KrakenLover said:

    Yes, TRWTF is that this system doesn't support recurring meetings and that in 2013 we are still running 32 bit "enterprise" systems that can't support relatively distant dates.
     

    I smell an opportunity for selling them a 64-bit upgrade.



  • @Cassidy said:

    @KrakenLover said:

    Yes, TRWTF is that this system doesn't support recurring meetings and that in 2013 we are still running 32 bit "enterprise" systems that can't support relatively distant dates.
     

    I smell an opportunity for selling them a 64-bit upgrade.

    That would be great if they had any control over the server.  :P  Being as the system is cloud based, they are locked into 32 bit hardware/software and into an older version of PHP which doesn't even support garbage collection (constantly hit out of memory errors because of this).  So they're stuck, at least until this cloud software company decides to upgrade their stuff.

     



  • @KrakenLover said:

    ...an older version of PHP which doesn't even support garbage collection (constantly hit out of memory errors because of this).

    PHP has used reference counts for a long time. If you're hitting OOM errors, it's either a memory leak or some operation is trying to use more memory than PHP is permitted.



  • @morbiuswilters said:

    @KrakenLover said:
    ...an older version of PHP which doesn't even support garbage collection (constantly hit out of memory errors because of this).

    PHP has used reference counts for a long time. If you're hitting OOM errors, it's either a memory leak or some operation is trying to use more memory than PHP is permitted.

     

    Yeah, PHP gets configured with a memory limit.  Defaults for earlier versions (4.x) tended to be ridiculously low (8MB?  WTF?) Surely this cloud service is aware that their server environment is misconfigured for their application?



  • @sprained said:

    @morbiuswilters said:

    [quote user="KrakenLover"]...an older version of PHP which doesn't even support garbage collection (constantly hit out of memory errors because of this).

    PHP has used reference counts for a long time. If you're hitting OOM
    errors, it's either a memory leak or some operation is trying to use
    more memory than PHP is permitted.

     

    Yeah, PHP gets
    configured with a memory limit.  Defaults for earlier versions (4.x)
    tended to be ridiculously low (8MB?  WTF?) Surely this cloud service is
    aware that their server environment is misconfigured for their
    application?

    [/quote] Memory limit is around 512.  They set it to this specifically because they know that their application is very memory inefficient, and for the reasons below.

     @morbiuswilters said:

    @KrakenLover said:
    ...an older version of PHP which doesn't even support garbage collection (constantly hit out of memory errors because of this).

    PHP has used reference counts for a long time. If you're hitting OOM errors, it's either a memory leak or some operation is trying to use more memory than PHP is permitted.

    Yes, which works well enough in PHP 5.3+ combined with other improvements made in later versions, but this cloud service uses PHP 5.2 - which only uses reference counting and does not have a garbage collector.  Installing the same system on a server running PHP 5.3+ sees dramatic reduction in memory usage overall. But since most of my clients use the cloud service instead of hosting locally, all my code has to conform to the restrictions of the cloud version.

    The application itself was not coded very well, and uses a fully custom ORM that severely overreaches its domain, exacerbating the problem.  It is ludicrously inefficient; and I doubt the original developers even knew or cared what a memory leak was when they first developed the framework 10 or so years ago.  And we all know PHP isn't exactly the kind of language the naturally enforces good coding practices.

    It's to the point now where I have to ignore the ORM anytime I expect my code to work with more than a dozen records in a single request, and hand code all my SQL.  For some things, the speed-up I get by doing things the non-ORM/OOP way is in excess of ten thousand times (when you're dealing with hundreds of thousands of records, this changes a process that took 10 hours before down into something that takes a second or two; and more often than not, changes a process that simply cannot run at all to one that does so easily).



  • @KrakenLover said:

    Yes, which works well enough in PHP 5.3+ combined with other improvements made in later versions, but this cloud service uses PHP 5.2 - which only uses reference counting and does not have a garbage collector.  Installing the same system on a server running PHP 5.3+ sees dramatic reduction in memory usage overall.

    That's not really PHP's fault, then. Whoever designed your app apparently didn't understand (or care to understand) how refcounts work, and so coded in a lot of circular references. I prefer refcounts to GC because at least with refcounts I know objects are destroyed as soon as they go out of scope.

    Regardless, I'm still confused how this fails so badly on your system. Do you have long-running PHP processes (like daemons, which would be pretty WTFy) or something? If you're just using mod_apache, even circular references should be cleaned up when the request ends..



  • @morbiuswilters said:

    That's not really PHP's fault, then. Whoever designed your app apparently didn't understand (or care to understand) how refcounts work, and so coded in a lot of circular references. I prefer refcounts to GC because at least with refcounts I know objects are destroyed as soon as they go out of scope.

    Regardless, I'm still confused how this fails so badly on your system. Do you have long-running PHP processes (like daemons, which would be pretty WTFy) or something? If you're just using mod_apache, even circular references should be cleaned up when the request ends..

    Well, I won't get into a debate about the merits of some of PHP's design choices or PHP's reputation. The simple fact is that because of a number of factors, this system runs poorly in PHP 5.2, and runs a little better (though still poorly) on 5.3 because of the presence of a garbage collector.  Since the cloud environment is locked into 5.2 for the foreseeable future, I have to deal with it.

    No, just regular old page requests suffer from these problems.  And many go away on 5.3, especially for longer running processes that are schedule cron job type things and those that work with bulk data.

    It is a very common thing for this system to die from an out of memory error the very first time you launch the home page.  So you have to temporarily increase the memory limit to 512 or higher for that one initial request, then turn it back down to whatever you want (or just leave it at 512, which is what I do).  This system's ORM is terrible, inefficient, and a general pain to work with.

    Let's say I want to update 100 Customer records (each Customer being an object in the ORM).  Instantiating 100 Customers one at a time (setting the $customer variable to NULL after each one is done, before instantiating the new one) has the same memory profile as instantiating them all at once and working with them concurrently in 5.2.  In order to do anything useful, you have to also load the object's relationships, which instantiates yet more objects.  Loading a single Customer can take hundreds or thousands of MySQL queries, to say nothing of the CPU load (TONS of string processing, comparison, filtering, html-encoding, etc. for every field for every object).

    The object model is so convoluted and complex that it isn't even worth the time to figure out where all the resource usage is coming from; I can't make core modifications to the system anyway.  It's much faster, more reliable, and less bug-prone by a factor of at least 10, to just hard code the SQL stuff and kick the ORM to the side.  Sometimes just getting some function to work on the cloud takes so much refactoring and optimization I feel like I'm writing C.



  • @KrakenLover said:

    No, just regular old page requests suffer from these problems.  And many go away on 5.3, especially for longer running processes that are schedule cron job type things and those that work with bulk data.

    Yeah, it sounds like you've got some badly-coded jobs that deal with large quantities of data and leave circular refs all over which will chew up memory.

    @KrakenLover said:

    Loading a single Customer can take hundreds or thousands of MySQL queries, to say nothing of the CPU load (TONS of string processing, comparison, filtering, html-encoding, etc. for every field for every object).

    LOL, ouch.

    @KrakenLover said:

    It's much faster, more reliable, and less bug-prone by a factor of at least 10, to just hard code the SQL stuff and kick the ORM to the side.

    I honestly don't even bother with an ORM in PHP or Java; I just do straight SQL because it's faster to develop and less error-prone.



  • @spamcourt said:

    Everyone should switch to RFC 2550-compliant dates.
    While RFC 2550 might have the right idea about future-proofing, in their estimation of CPU speeds in Y10k they totally forget to take into account the limitation due to planck time.



  • @morbiuswilters said:

    I have it on good authority that the Reptilians will have conquered Earth and enslaved all surviving humans by 2030--2035 at the latest--and their system of time can't be expressed using integral numbers at all.

    Well, I have it on good authority that we have until A.D. 2101 before war was beginning.



  • @KrakenLover said:

    "This meeting has to go on FOREVER!".

    I wouldn't worry, everyone involved with the eternal meeting will have killed themselves long before 2038.


  • Discourse touched me in a no-no place

    @morbiuswilters said:

    I honestly don't even bother with an ORM in PHP or Java; I just do straight SQL because it's faster to develop and less error-prone.
    It's not too bad when you want to do looking up a row… errr, object by ID and updating of that object. (That's the part that's really tedious in Java.) But any query that isn't just a get-one-object-by-ID? Write it yourself and save your brain from having to learn a retarded half-cousin of SQL when the real thing is available.


Log in to reply