Earlier quoted context omitted.
+1 for strongly typed and compile-time checked, but I'm still not a fan of a sub-language within a string literal. The language already has syntax to structure things, why make a separate language within strings?
> The language already has syntax to structure things I don’t think the language has anything suitable for these purposes. What did you have in mind?
Do not use 'week year': YYYY
81–90 of 94 posts
Re: Do not use 'week year': YYYY
#82I understand that "week year" is basically a payroll creation, but I am a bit concerned about the last few days of 2021 were logged as 2022, and Jan 1st 2022 was even logged as 2023. The last few days of 2021 logged as 2022 makes sense for payroll, but how the heck is Jan 1st 2022 put in the 2023 year?
> The last few days of 2021 logged as 2022 makes sense for payroll, but how the heck is Jan 1st 2022 put in the 2023 year? First off, I think you have a typo(?) with the "2023"? Because: * https://www.epochconverter.com/weeks/2022 The reason(s) why the week system was designed: > * All weeks have exactly 7 days, i.e. there are no fractional weeks. > * Every week belongs to a single year, i.e. there are no ambiguous o…
It's not just payrolls, it's also things like deliveries or synchronisation. And saying "monday week 15" (or writing "W15 mon") aside from being short and precise can give a better ground for synchronisation or collision than "April 11th" e.g. the person you're talking to might know that every monday would be an issue and be able to say that that's not an option before even looking it up.
Re: Do not use 'week year': YYYY
#83Earlier quoted context omitted.
The point is there's nothing about YYYY vs yyyy telling you at a glance that there is a significant semantic difference in the result. Imagine an API which had methods 'getYear()' and 'GET_YEAR()' where the latter returns the payroll week year, while the former returns the, you know, actual year. That's what having YYYY produce the week year feels like - a blatant violation of the principle of least surprise. Which i…
> The point is there's nothing about YYYY vs yyyy telling you at a glance that there is a significant semantic difference in the result. There's the part that the entire LDML datetime grammar works like that. Literally the next letter in your pattern will make it clear: M is the month, and m is the minute. Which, granted, makes "y" designating the calendar year less than ideal as you'd want to pair Y with M, rather t…
But there's a little bit of a difference between mm/MM being minutes/months, where at least as someone thinking about datetime formatting you likely have a concept that the concepts of minutes and months are plausible things 'm' might stand for, vs. yyyy/YYYY where unless you've come across it before, the idea that there might be an inbuilt concept of a 'week year' is likely not going to be something that occurs to you.
I suppose the fact that both 'yyyy/mm/dd' and 'YYYY/MM/DD' produce values that are obviously wrong most of the time should be enough of an incentive for developers to go and look. up the codes. But that said, 'YYYY/MM/DD' produces what looks like the right answer for most of January...
Re: Do not use 'week year': YYYY
#84> The reference time used in these layouts is the specific time stamp: 01/02 03:04:05PM '06 -0700 (January 2, 15:04:05, 2006, in time zone seven hours west of GMT). That value is recorded as the constant named Layout, listed below. As a Unix time, this is 1136239445.
> RFC3339 = "2006-01-02T15:04:05Z07:00"
Re: Do not use 'week year': YYYY
#85You know, assuming the earth's frame of reference....
Re: Do not use 'week year': YYYY
#86Display timestamps however the user wants.
Do not roll your own timestamp code. See "Falsehoods programmers believe about time".
Re: Do not use 'week year': YYYY
#87Earlier quoted context omitted.
I used the JS Date API for the first time a few months ago, and wrote something like date.getYear() + "-" + date.getMonth() + "-" + date.getDay() in the hope of getting something like "2022-1-4". The actual result for that date is "122-0-2" - not a single component of the date was what I expected.
date.toLocaleDateString ("fr-CA") would have got you there, but yea agreed 0 indexed months are whack. I'm sure you've read the docs since then but just for the viewers at home: s/getYear/getFullYear s/getDay/getDate getYear is oldfashioned, years since 1900. getDay is day-of-the-week, 0 for Sunday, 1 for Monday, etc
Why, if everything else in JS is 0 indexed? Isn't consistency a good thing in a language? If they'd gone the other way, wouldn't there be people here complaining that 1 indexing is whack?
Re: Do not use 'week year': YYYY
#88Earlier quoted context omitted.
date.toLocaleDateString ("fr-CA") would have got you there, but yea agreed 0 indexed months are whack. I'm sure you've read the docs since then but just for the viewers at home: s/getYear/getFullYear s/getDay/getDate getYear is oldfashioned, years since 1900. getDay is day-of-the-week, 0 for Sunday, 1 for Monday, etc
> 0 indexed months are whack Why, if everything else in JS is 0 indexed? Isn't consistency a good thing in a language? If they'd gone the other way, wouldn't there be people here complaining that 1 indexing is whack?
Re: Do not use 'week year': YYYY
#89Earlier quoted context omitted.
date.toLocaleDateString ("fr-CA") would have got you there, but yea agreed 0 indexed months are whack. I'm sure you've read the docs since then but just for the viewers at home: s/getYear/getFullYear s/getDay/getDate getYear is oldfashioned, years since 1900. getDay is day-of-the-week, 0 for Sunday, 1 for Monday, etc
> 0 indexed months are whack Why, if everything else in JS is 0 indexed? Isn't consistency a good thing in a language? If they'd gone the other way, wouldn't there be people here complaining that 1 indexing is whack?
Re: Do not use 'week year': YYYY
#90Earlier quoted context omitted.
> The language already has syntax to structure things I don’t think the language has anything suitable for these purposes. What did you have in mind?
I don't know about Rust. Several people responded that Java already has a builder interface for creating a format string. That is possibly more type erased than the Rust macro equivalent. In C++ I would use variadic templates, as I originally proposed in my root comment: `format(year(), '/', ...)`.
That components have parameters makes the non-literal approach even less compelling: take this which can produce the likes of “2:34:56pm”:
format_description!("[hour padding:none repr:12]:[minute]:[second][period case:lower]")
For reference, that is equivalent to this: use time::format_description::{FormatItem, component::Component, modifier::{Hour, Minute, Second, Period, Padding}};
[
FormatItem::Component(Component::Hour(Hour { padding: Padding::None, is_12_hour_clock: false })),
FormatItem::Literal(b":"),
FormatItem::Component(Component::Minute(Minute { padding: Padding::Zero })),
FormatItem::Literal(b":"),
FormatItem::Component(Component::Second(Second { padding: Padding::Zero })),
FormatItem::Component(Component::Period(Period { is_uppercase: false, case_sensitive: true })),
]
You could easily provide a prettier DSL so that you could write something like this: use time::format_description::shorthand::{HOUR, MINUTE, SECOND, PERIOD, literal};
[
HOUR.padding_none().repr_12(),
literal(":"),
MINUTE,
":".into(), // even this if you wanted
SECOND,
PERIOD.case_lower(),
]
This wouldn’t be awful in the absence of the parse method, but really, once you have that, the format_description macro is just what you want: compact, checked at compile time, and matching a runtime equivalent which can take user-provided format strings.(Now there are two or three changes I’d prefer to make to format_description’s syntax: I’d use = instead of :, the two being generally very similar but : far more regularly occurring in literal parts, so that the different = would make it scan better; and I think that escaping opening square brackets by doubling them but not requiring doubling for closing square brackets was a particularly bad idea; and I’m mildly inclined to prefer {} to []. So I might end up with "{hour padding=none repr=12}:{minute}:{second}{period case=lower}".)