1

Is there a correct way to go about grabbing the name of a day, when you have the short version, such as the following:

mon
tue
wed
thu
fri
sat
sun

I don't need an actualy "date" or time or anything, I just need the string for the full date name.

Joshua Soileau
  • 2,933
  • 9
  • 40
  • 51
  • Yes a [Map object](https://developer.mozilla.org/tr/docs/Web/JavaScript/Reference/Global_Objects/Map) for instance. – Redu Sep 10 '17 at 17:47
  • A dictionary maybe ? Something like `days={mon:"Monday", etc...}`, then `days["mon"]` gives `"Monday"`. –  Sep 10 '17 at 17:48
  • Feels like this question is better asked on the Code Golfing StackExchange. One JavaScript solution: `dayName=s=>\`${s}${{tue:'s',wed:'nes',thu:'rs',sat:'ur'}[s]||''}day\`` (though it doesn't capitalize and gives ugly answers for things that are not valid day abbreviations). – Ray Toal Sep 10 '17 at 18:14

4 Answers4

8

A simple associative array (read object) dictionary would suffice:

var days = {
  'mon': 'Monday',
  'tue': 'Tuesday',
  'wed': 'Wednesday',
  'thu': 'Thursday',
  'fri': 'Friday', 
  'sat': 'Saturday',
  'sun': 'Sunday'
}

Now, you can access them as follows:

var day  = 'mon',
    full = days[day]; // full === 'Monday';
BenM
  • 52,573
  • 26
  • 113
  • 168
  • Why not use a function with some `switch(dayNameShort): { case X: return Y }, case ...` clauses, so you could handle falsy values and write tests for it? I think proper naming should be a part of a good answer, too. Why not name your assoc. array `shortDayNameToLong` or something similar? Or even so - you could have a parent object `DayNameConverter` and have current `days` object named `shortToLong` use it like `DayNameConverter.shortToLong[myShortDayName]`? Just tinkering with options here. – Denialos Sep 10 '17 at 18:03
  • Sometimes there's a trade-off between simplicity and overheads. Switch statements would be slower of course, as would functions (with added overheads). Agreed, if there's a possibility that i18n is a requirement, a more robust solution is required, but this one seems to suit the OP's question just fine, without any added complexity or speed impairments. – BenM Sep 10 '17 at 18:08
  • 1
    Mate, did you just call a fully testable and able-to-hand-falsy-values solution (a function) an overhead? Are you serious? There's no overhead here - there's just increased testability and maintainability of the code. That's it. Also, a more flexible and maintainable solution may possibly be slower... But, let me ask - who cares about the performance in such a simple case? Well, nobody. – Denialos Sep 10 '17 at 20:25
  • @Denialos I disagree. The question is fundamental enough to make this a good answer. – Aluan Haddad Sep 11 '17 at 19:35
2

small enhancement to @BenM answer

var Days = {
  'mon': 'Monday',
  'tue': 'Tuesday',
  'wed': 'Wednesday',
  'thu': 'Thursday',
  'fri': 'Friday', 
  'sat': 'Saturday',
  'sun': 'Sunday',
   getFullName: function(day) {
    return this[day];
   }
}

Days.getFullName("mon");
No one
  • 1,130
  • 1
  • 11
  • 21
0

@BenM already added an answer. Just extending his answer, 

var days = {
  'mon': 'Monday',
  'tue': 'Tuesday',
  'wed': 'Wednesday',
  'thu': 'Thursday',
  'fri': 'Friday', 
  'sat': 'Saturday',
  'sun': 'Sunday'
}

var shortDays = ['mon','tue','wed','thu','fri','sat','sun'];


var getFulldays = shortDays.map(function(day){
  return days[day]
})

console.log(getFulldays)
Ved
  • 11,837
  • 5
  • 42
  • 60
0

In JS as of ES6, actually the Map object is the proper way of doing this job since it is more efficient than object access. A very simplistic implementation is as follows;

var days = new Map([["mon", 'Monday'],
                    ["tue", "Tuesday"],
                    ["wed", "Wednesday"],
                    ["thu", "Thursday"],
                    ["fri", "Friiday"],
                    ["sat", "Saturday"],
                    ["sun", "Sunday"]
                    ]);
console.log(days.get("thu"));
Redu
  • 25,060
  • 6
  • 56
  • 76
  • Do you have metrics on the relative efficiency? This is far less readable. Also, `Map` exists primarily to support the use case where non-strings are used as keys – Aluan Haddad Sep 11 '17 at 19:37
  • @Aluan Haddad I had done a comparison on [array duplicates removal](https://stackoverflow.com/a/37462984/4543207)... Map seems to do 50% better when there isn't so many duplicates and in this case we have no duplicates. – Redu Sep 11 '17 at 19:54
  • I don't see how it applies because we're not removing anything at all. This also has a penalty of creating 8 array objects unnecessarily. That might get optimized out by a modern VM or it might not make a difference. What's certain is that the readability of this is poor. Maybe times have changed and I'm stuck in the past but this feels like throwing away the natural expressiveness of the language. – Aluan Haddad Sep 11 '17 at 19:59
  • @Aluan Haddad OK I guess you refer some crooked JSPerf results... I would advise you to run your own test instead. You will notice that Map operation is significantly (25~30% in Chrome; +50% in FF) takes shorter both for number and string keys. I did [another detailed LUT vs MAP test](https://repl.it/KxV5/1) please check. Don't be confused with the asynchronous part that's only for collecting test data from an API. We are checking 1927 keys randomly 2298 times and repeat this 50 times to get average performance. So Map is the right way to do this job and also the fastest. – Redu Sep 12 '17 at 11:25
  • We are talking about 7 items. I'm intimating premature optimization if anything. Using a map for this is bad style. Bad answer. – Aluan Haddad Sep 12 '17 at 11:33
  • @Aluan Haddad There may be only 7 entries but one or many users may need to access it a zillion times. Unlike ordinary objects, the Map object is introduced and optimized specifically for this job. This isn't for micro optimization but for showing the proper way of doing this job as of ES6 which renders this answer perfectly valid. – Redu Sep 12 '17 at 11:55
  • Maps were introduced to allow non-string, especially by identity, keys. Even if they _perform_ slightly better in this scenario it is a bad trade-off and I have no need to benchmark it to find that out. It reads badly. – Aluan Haddad Sep 12 '17 at 11:59