Time Zone Converter



  • I found this gem repeated in more than 10 different Java classes. Starting from the first instance that flat out did not work, each successive copy had gradual improvements. I present to you the final version copied in at least 3 of the 10 classes I found.

    Whenever they needed to have dates represented in different time zones, they would use this pattern from hell

          private static SimpleDateFormat dateFormatGMT = new SimpleDateFormat("yyyy-MM-dd HH🇲🇲ss");
          private static SimpleDateFormat dateFormatIST = new SimpleDateFormat("yyyy-MM-dd HH🇲🇲ss");
          private static SimpleDateFormat dateFormatGMT1 = new SimpleDateFormat("HH:mm");
          private static SimpleDateFormat dateFormatIST1 = new SimpleDateFormat("HH:mm");
    
      static {
          dateFormatGMT.setTimeZone(TimeZone.getTimeZone("GMT"));
          dateFormatIST.setTimeZone(TimeZone.getTimeZone("IST"));
          dateFormatGMT1.setTimeZone(TimeZone.getTimeZone("GMT"));
          dateFormatIST1.setTimeZone(TimeZone.getTimeZone("IST"));
      }
    

    public static String convertGMTtoISTTimeZone(String strGMT) {
    try {
    if(strGMT != null && !"".equals(strGMT)) {
    Date dateGMT = dateFormatGMT.parse(strGMT.trim());
    return dateFormatIST.format(dateGMT);
    } else {
    return "";
    }
    } catch(ParseException ex) {
    logger.error("Exception: convertGMTtoISTTimeZone: " + ex.getMessage());
    }
    return strGMT;
    }
    public static String convertISTtoGMTTimeZone(String strIST){
    try {
    if(strIST!=null && !"".equals(strIST)){
    Date dateIST=dateFormatIST.parse(strIST.trim());
    return dateFormatGMT.format(dateIST);
    }else{
    return "";
    }
    } catch (ParseException ex) {
    logger.error("Exception: convertISTtoGMTTimeZone: " + ex.getMessage());
    }
    return strIST;

    }
    public static String convertGMTtoISTTimeZone1(String strGMT) {
    try {
    if(strGMT != null && !"".equals(strGMT)) {
    Date dateGMT = dateFormatGMT1.parse(strGMT.trim());
    return dateFormatIST1.format(dateGMT);
    } else {
    return "";
    }
    } catch(ParseException ex) {
    logger.error("Exception: convertGMTtoISTTimeZone1: " + ex.getMessage());
    }
    return strGMT;
    }
    public static String convertISTtoGMTTimeZone1(String strIST){
    try {
    if(strIST!=null && !"".equals(strIST)){
    Date dateIST=dateFormatIST1.parse(strIST.trim());
    return dateFormatGMT1.format(dateIST);
    }else{
    return "";
    }
    } catch (ParseException ex) {
    logger.error("Exception: convertISTtoGMTTimeZone1: " + ex.getMessage());
    }
    return strIST;

    }

    I seem to have lost the first version, but the code tells a funny story of how the author banged his head around this for quite a while, with commented code tossed everywhere and method names numbering to the 10s digit.



  • This should go on the frontpage. This is so wrong in so many ways I don't even want to enumerate them.

     



  •  The basic idea seems correct to me. What is the worse than failure?



  • @Jonathan said:

     The basic idea seems correct to me. What is the worse than failure?

    For starters, dates as strings are silly strings. This whole thing would not have been necessary had it simply used date objects instead.



  • @OhNoDevelopment said:

    @Jonathan said:

     The basic idea seems correct to me. What is the worse than failure?

    For starters, dates as strings are silly strings. This whole thing would not have been necessary had it simply used date objects instead.

     

    Dates as strings are necessary in order for them to be human readable.

    So this code doesn't meet your requirements? You haven't shown us your requirements and this code is basically correct for what it does.



  •  It may not always be appropriate to work with date objects first and translate them to human-readable strings second, but that's the way to bet.

     



  • @Jonathan said:

    Dates as strings are necessary in order for them to be human readable.
     

    Then you transform them just as you're about to display them to a human. 

    For all other operations, it makes sense to leave them as a Date object.



  • @Cassidy said:

    @Jonathan said:

    Dates as strings are necessary in order for them to be human readable.
     

    Then you transform them just as you're about to display them to a human. 

    For all other operations, it makes sense to leave them as a Date object.

     

    So far we haven't been given any requirements so we don't know if any other operations are needed. The unknown requirements may or may not call for this code.

    So the worse than failure here is expecting requirements to be assumed, which is the worst of all worse than failures.



  • @Jonathan said:

    So the worse than failure here is expecting requirements to be assumed
     

    .. including the necessity for them to be human-readable?



  • @Jonathan said:

    Dates as strings are necessary in order for them to be human readable.

    If you want to output your date, use DateFormat.format(). If you want to view the date during debugging, any decent debugger will call toString for you. Where else would it be important that a date is human readable?

    @Jonathan said:

    So far we haven't been given any requirements so we don't know if any other operations are needed. The unknown requirements may or may not call for this code.

    We haven't. But the fact that his bit is repeated in dozens of different classes makes it rather unlikely that this is only used to read dates from one text file and write them into another.



  • @Jonathan said:

    @Cassidy said:

    @Jonathan said:

    Dates as strings are necessary in order for them to be human readable.
     

    Then you transform them just as you're about to display them to a human. 

    For all other operations, it makes sense to leave them as a Date object.

     

    So far we haven't been given any requirements so we don't know if any other operations are needed. The unknown requirements may or may not call for this code.

    So the worse than failure here is expecting requirements to be assumed, which is the worst of all worse than failures.

     

    You should newer store or handle dates as strings. The only time you may have a date as a string is when doing input/output, but then the only thing you should do with that string is to convert it to/from a Data object.   

     

     


  • ♿ (Parody)

    TRWTFs

    @Jonathan said:

    What is the worse than failure?

    @Jonathan said:

    So the worse than failure here is expecting requirements to be assumed, which is the worst of all worse than failures.



  • @boomzilla said:

    The real worse than failures

    @Jonathan said:

    What is the worse than failure?

    @Jonathan said:

    So the worse than failure here is expecting requirements to be assumed, which is the worst of all worse than failures.

    FTFY



  • @Jonathan said:

    So this code doesn't meet your requirements? You haven't shown us your requirements and this code is basically correct for what it does.
    I don't see how this matters at all. Some of the worst code ever written meets all of the stated requirements. "It works" and "It's good" are orthogonal concepts.



  • @mt@ilovefactory.com said:

    Data object
     

     

     Now I'm envisioning a whole new WTF where some cow-orker takes this spelling at face value and starts creating a kitchen-sink object.  And then of course you need a kitchen-sink factory, and--

     

    ...I'll get me coat.

     

     



  • If you're doing multi-threaded code and using these methods amongst many threads, then you will likely have a problem. It is commonly known (or, rather, should be) that *Format, especially *DateFormat objects are not thread safe ... they do calculations with member variables instead of temporary variables within the methods. If you must use these, make them externally thread safe ... better yet, make a public static final String DATE_FORMAT to represent the format and create a formatter at need ... or otherwise wrap the instantiation of *DateFormats...



  • @mt@ilovefactory.com said:

    You should newer store or handle dates as strings.
     

    Only archive them if they're older, then?

    I think Jonathan's point still holds - that without further information we're making assumptions. However, I still feel that if you're performing date operations, using a Date object with associated methods is more efficient than trying to manage them as Strings.



  • @mt@ilovefactory.com said:

    You should newer store or handle dates as strings. The only time you may have a date as a string is when doing input/output, but then the only thing you should do with that string is to convert it to/from a Data object.

    A worse than failure IMO is saying never, when what you mean is that you can't think of any instance in which anyone would ever want to do such a thing, unless they're really clueless. Be that as it may, even if you're right, there is no real excuse for saying never, when you don't mean never. Especially if it's some kind of rule all of us seem to have to obey.

    The reason, of course, is the far-fetched case that may or may not pop up, in which doing what you said one must never do, makes perfect sense.



  • Just an obversation.... EVERY timezone related implementation I have EV ER seen is a WTF....and this includes the ones I have written over the past 35+ years....

    The concept of timezones is so convoluted, that it is practically impossible to every write a comprehensive system in any programming language.  One of my favorites (circa 1982) was the creation of a dedicated system that needed a mechanical switch to select the "delta from GMT"..whole hours were not a problem, but things were complicated by the 00:30:00 offsets in many places, and the fact that there was even a single 00:15:00 offset. The increase in hardware costs for this was quite significant (as a percentage of the project)...

    But worse than the above is determining what the local time was in a loction on a given historical date or what the local time is for a given geographic location.

     1) A train travels through 10 cities for the past 150 years. There are paper logs of the local arrival and deptarture from each station (which may be in a different timezone - especially relating to DST)...calcuate the speeds (distance/time) between each station over time

    2) A orbiting camera is taking pictures of the ground. Timestamp each image with the "local" time....

     Suggestion: (which will never be adopted)

     1) Eliminate the concept of local time, use UTC/GMT for EVERYTHING.

      2) If "local time" must be observed, then make it truely local, and based on "seconds since sunrise" given latitude/longitude/elevation



  • @toon said:

    A worse than failure IMO is saying never, when what you mean is that you can't think of any instance in which anyone would ever want to do such a thing, unless they're really clueless.

    <pedant>He didn't actually say "never"</pedant>

    <nonpedant>But if that's what he meant, then I agree with your statement</nonpedant>

    @TheCPUWizard said:

    Just an obversation.... EVERY timezone related implementation I have EV ER seen is a WTF....

    I don't see how. Most languages provide libraries to handle this stuff.

    @TheCPUWizard said:

    2) A orbiting camera is taking pictures of the ground. Timestamp each image with the "local" time....

     Suggestion: (which will never be adopted)

     1) Eliminate the concept of local time, use UTC/GMT for EVERYTHING.

      2) If "local time" must be observed, then make it truely local, and based on "seconds since sunrise" given latitude/longitude/elevation

    My proposed method would be:

    3) create a date object initialised to GMT. When a timestamp is required, return that time in the context of the timezone.

     



  • @TheCPUWizard said:

      2) If "local time" must be observed, then make it truely local, and based on "seconds since sunrise" given latitude/longitude/elevation

    Yeah, let's do that: I'm sure that won't be a wasp hive of WTFs waiting to happen *facepalm*.


  • Discourse touched me in a no-no place

    @TheCPUWizard said:

    EVERY timezone related implementation I have EV ER seen is a WTF....and this includes the ones I have written over the past 35+ years...
    The ones that people are usually recommended to use (e.g., Joda Time) are distinctly less WTFy than most, but the real problems tend to stem from the fact that politicians just can't seem to leave well alone. Then we'd be able to consistently figure out how to turn a universal timestamp into a local one (and go back again) and all would be peachy.

    But timezones themselves are thoroughly full of WTF and its a constantly growing heap of WTF at that.
    @TheCPUWizard said:

    But worse than the above is determining what the local time was in a loction on a given historical date or what the local time is for a given geographic location.
    Hint: when you get back to dealing with locally-determined sun-time (with times getting uncertain on those days when the local kids break the sundial or if it is a bit cloudy) then it is time to give up. Some sorts of accuracy just aren't needed.



  • @toon said:

    @TheCPUWizard said:
      2) If "local time" must be observed, then make it truely local, and based on "seconds since sunrise" given latitude/longitude/elevation

    Yeah, let's do that: I'm sure that won't be a wasp hive of WTFs waiting to happen *facepalm*.

    That's what we did before timezones. We found out quickly that as soon as you could move 30 MPH or so and send a message at the speed of electricity, the system was a complete disaster. That's why railroads invented timezones in the first place. (At least here in the States, railroads installed the original telegraph network also.)



  • In response to multiple replies....

     A) When I said "implementations" I was not just referring to "computer libraries" or custome code..The implementation by humans is indeed the root of the problem. That being said, I maintain my position. Many libraries are better than others, NONE are free of WTF conditions [nor do I believe they ever will be becuase of the former]

    B) Going to pure GMT/UTC was a serious suggestion. "Seconds PAst Sunrise" was sarcasm, OBVIOUSLY it is useless from any practical consideration...but it is really no different than the totaly screwed implementation of timezones (and especially DST) around the globe.


Log in to reply