Skip to content
This repository has been archived by the owner on Apr 13, 2023. It is now read-only.

datestamp() function #645

Open
gavinking opened this issue Dec 3, 2016 · 6 comments
Open

datestamp() function #645

gavinking opened this issue Dec 3, 2016 · 6 comments

Comments

@gavinking
Copy link
Contributor

Currently ceylon.time can produce ISO timestamps. I would also like to have a convenience function for rendering "date stamps", of form 20161102.

@DiegoCoronel @luolong WDYT?

@gavinking gavinking added this to the 1.3.2 milestone Dec 3, 2016
@quintesse quintesse modified the milestones: 1.3.2, 1.3.3 Mar 3, 2017
@luolong
Copy link
Contributor

luolong commented Apr 21, 2017

parseDate not good enough?

@luolong
Copy link
Contributor

luolong commented Apr 21, 2017

or do you mean the other way around — that would be Date.string, I guess...

@gavinking
Copy link
Contributor Author

Nope, it uses this format:

"Returns ISO-8601 formatted String representation of this date.\n
 Reference: https://en.wikipedia.org/wiki/ISO_8601#Dates"
shared actual String string 
        => "``year.string.padLeading(4, '0')``-``month.integer.string.padLeading(2, '0')``-``day.string.padLeading(2, '0')``";

I want, literally: 20161102.

@luolong
Copy link
Contributor

luolong commented Apr 21, 2017

Well, the trouble here is that all those *.string methods are currently returning similarly formatted output across the board.

Date.string returns yyyy-mm-dd, Time.string returns hh:mm:ss, DateTime.string returns Date.string + 'T' + Time.string and Instant (the timestamp) simply returns ZoneDateTime.string at UTC.

I suppose the correct way to approach this would be to put those specific formats into ceylon.formatter module.

@luolong
Copy link
Contributor

luolong commented Apr 21, 2017

On the other hand, the YYMMDD and HHmmss formats are also valid ISO representations. so it would be relatively easy to change default output to the shorter variant.

I personally dislike those though. They are useful at times, but I prefer to keep the variants with dashes and colons as default textual representation.

@gavinking
Copy link
Contributor Author

Well, the trouble here is that all those *.string methods are currently returning similarly formatted output across the board.

And I think that's perfectly fine. I don't want to change that.

But the shorter YYMMDD and HHmmss formats are also sometimes useful, and I think we should have convenience functions (or attributes, perhaps) for generating them.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants