# Strftime & strptime bug #27239 is present on all platforms, not just Windows

**URL:** <https://discourse.julialang.org/t/strftime-strptime-bug-27239-is-present-on-all-platforms-not-just-windows/11191>\
**Category:** Internals & Design\
**Tags:** bug\
**Created:** [May 27, 2018, 10:30pm UTC](https://discourse.julialang.org/t/strftime-strptime-bug-27239-is-present-on-all-platforms-not-just-windows/11191 "2018-05-27T22:30:53Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![ScottPJones](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/scottpjones/32/146_2.png) [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)\
**Post date:** [May 29, 2018, 1:45pm UTC](https://discourse.julialang.org/t/strftime-strptime-bug-27239-is-present-on-all-platforms-not-just-windows/11191/8 "2018-05-29T13:45:06Z")

</div>

> [@UTF8 space/difficulty tradeoffs](https://discourse.julialang.org/t/utf8-space-difficulty-tradeoffs/11205/2):
>
> > [@UTF8 space/difficulty tradeoffs](https://discourse.julialang.org/t/utf8-space-difficulty-tradeoffs/11205/1):
> >
> > concerned me about the “UTF-8 is always best” mentality, text from the languages of the vast majority of the world’s population generally takes up 50% to 200% more space encoded with `UTF-8`
> 
> This is correct, but another perspective on this issue is that space is usually cheap compared to programmer time and the cost of bugs, so economizing on the latter by choosing a single representation is reasonable in many circumstances.

To make myself more clear: I feel that the bugs in `strftime` and `strptime` come from a lack of awareness of how character set encodings are used around the world, stemming from this `UTF-8` only or centric view.  
Also, many other bugs that I’ve seen over the last 3 years in Julia itself, or in many of the packages that deal with strings (such as JSON, CSV, all of the database wrappers) come from either 1) lack of identification of the character set / encoding (such as in the `strftime`/`strptime` case), assuming everything would be `UTF-8`, or 2) issues caused by the complexity of dealing with multi-codeunit encodings such as `UTF-8`, such indexing into the middle of UTF-8 sequences, incorrectly specifying the end of a range of characters [lastindex vs. sizeof, for example], etc.

I agree that having an single recommended string type (but _not_ necessarily a single internal string _representation_!) for most use, especially with the high numbers of Julians who are researchers, professors, mathematicians, scientists of all types but not so many CS types, is a good thing, but it should be something that is easy for them to use, which is why I’ve been working on a `UniStr` type that does not have the issues that complex encodings such as `UTF-8` have.  
It also needs to be able to handle in an easy fashion converting back and forth to other encodings such as `UTF-8`, `UTF-16`, `Cwstring` (i.e. either `UTF-16` or `UTF-32` depending on platform), taking care of any system conversions (such as with `strftime`) to/from the system’s character set / encoding for that function / locale (i.e. `LC_TIME`).

---

_[View the full topic](https://discourse.julialang.org/t/strftime-strptime-bug-27239-is-present-on-all-platforms-not-just-windows/11191)._