[Feature] Unix formatting

[pbarbiero]

There are many cases where allowing unix style formats would let this library be used in many more places than it can be today. I myself have many cases where the list of included formats do not expose nearly enough flexibility or control to get the exact format needed.

Would you consider adding a new method (or extending the current one) such as .formatUnix() or something? It could also possibly be a secondary optional package to include which will extend spacetime with the unix formatting capability.

Background
This (and the lack of i18n support) is preventing me from adopting this library over moment which I desperately want to move on from for many reasons. This looks to be the first viable competitor because of the excellent timezone support (and all of my use-cases don't need the historical accuracy!)

Exposing this functionality (even as an optional module) I am sure would be useful for many others as well in the same situation as I am. There are many cases where legacy processes or database operations require an exact, specific format.

[ryanblock]

Hey @pbarbiero! Will definitely defer to @spencermountain on this (and #18) but he's on vacation for a bit.

Just wanted to let you know since we aim to be responsive to feedback!

[spencermountain]

absolutely! to be honest, i've never learned that case-sensitive thing, and that's probably why it doesn't have it right now. 😅
I'm not married to any of the current formatting methods, and it's not very clever. unixFormat() works for me, or it could fall-back to unix-formtting in .format(str) too... up to you!
cheeers

[brad-decker]

If there was a unix formatting option or a way to to string together some formatting options (including timezone abbreviation, which is one reason why i can't adopt this package just yet) i'd be way more likely to use this. All the other api methods/usability looks amazing.

[spencermountain]

ah yeah, you mean things like this EST | CST | MST | PST | EDT | CDT | MDT | PDT right?
we should definitely support timezone abbreviations, and even string formats like 'pacific time'.

for the unix-formatting stuff, is there a good resource for the spec? the best I could find is this. I think it's pretty weird, tbh. we could do it though.

thanks for the kind words.

[brad-decker]

i'd be down for non unix based, real world strings, so long as they can be strung together.

datetime.format('DAY MONTH YEAR, HOUR:MINUTE:SECOND TIMEZONEABBREV')

or something to that extent, instead of or in addition to the formats already provided.

[spencermountain]

hey, i like that idea.
thanks Brad

[pbarbiero]

@spencermountain while I agree to the uninitiated it looks weird, but for anyone who works with dates on a regular basis, having a single format that works everywhere is much more important than being readable on its own.

I wont argue against people who want a readable format, but supporting the unix format (like momentjs does) should still be a separate feature that is supported.

I am still trying to get some time to start on some of these things, I really do want to make this library an excellent alternative to a monolithic library that many people in my situation are forced to use.

[spencermountain]

yeah! exactly. thanks Phillip. can't wait.

[spencermountain]

( just found a good reference for the spec - http://unicode.org/reports/tr35/tr35-25.html#Date_Format_Patterns )

[spencermountain]

hey, got this working, check it out
https://runkit.com/spencermountain/5a0e33189de1da0012780a28

there's couple obscure templates i didn't write, like non-julian year formats and stuff.
win!

[johnyluyte]

Currently, using spacetime@2.2.0

spacetime.now().format("yyyy-MM-dd") will produce 2018-Feb-03

But according to the Date Field Symbol Table @spencermountain linked above, shouldn't it be 2018-02-03?
http://unicode.org/reports/tr35/tr35-25.html#Date_Format_Patterns

According to that article, the symbols should act like this:

M = 02
MM = 02
MMM = Feb
MMMM = February

But currently we have:

M = 1    (why? what does this mean?)
MM = Feb
MMM = February
MMMM = February

Am I missing something?

And my true problem here is: How do I get 2-digit Month? (i.e. 02 instead of Feb in this case)

[spencermountain]

hey Chun, good point. Looks like a bug.
Lemme take a look today
thanks!

[spencermountain]

hey, here's the fix
https://github.com/smallwins/spacetime/blob/master/test/format.test.js#L49
please check it out
cheers

[gregorskii]

Going back to this... seems like this is a bit off on timezone formatting too.

Can this not also support moment conversions? Seems like that's a more common formatting pattern for devs that convert over. Otherwise, the unix format works fine, except its different (and also does not seem to match).

Trying to convert a project from moment-timezone to this is not directly convertible due to the formatting differences.

If I understand the unix docs correctly, using format('z') should be the "Specific non-location format" of PST or PDT, but it results in the timezone name America/Los Angeles.

Ex:

format('h:mm a z, MMM d') results in 11:00 PM America/Los_Angeles, Nov 9

[spencermountain]

yeah, I agree. This formatting scheme we've got is pretty gross right now.
I can't figure it out, and I wrote it. Mixing unix-formatting and named formats has not played-out well.

Yeah, I like the idea of committing to parity with moment's .format(). we should call it .unixFormat or something.

creating #69