Format with a or A are different locally vs CI

[ghiscoding]

Hello, I am migrating away from MomentJS (finally) to your awesome library, however I'm having some issues with the a or A token. locally it shows as a.m. (or P.M for A in evening) but in the CI the exact same unit tests are failing because the format outputs am instead. Also what is a bit strange is that on the website, it shows as am but I run my code locally it shows as a.m.

I'm looking to get consistent result (I would prefer to always get am and not a.m.). I'm wondering if that difference is somehow coming from my locale setup? I'm in Canada in the Eastern TZ.

For example, with the format of 'YYYY-MM-DD hh:mm:ss a' on the website I see '2024-05-04 11:53:12 pm' but if I run it locally I see instead '2024-05-04 11:53:12 p.m.', why?

EDIT

Yeah after testing on MDN Intl.DateTimeFormat, the output is a.m. for en-CA but am for en-US. Are there any I can overwrite this behavior and always have the same result?

EDIT 2
ahh I found that I can pass en-US as 3rd argument of either parse() or format() and now it shows the am

Different Topic (question)

Also on a different topic, in Moment they had the .utc() function to mark the Date as UTC to differentiate local vs UTC date time. Are there any equivalent in Tempo? Below is an example taken from Moment's website

moment().format();     // 2013-02-04T10:35:24-08:00
moment.utc().format(); // 2013-02-04T18:35:24+00:00

I found that this might work, tzDate('2020-02-04', 'utc'), is that the correct way to get UTC? It gives me 2020-02-04T00:00:00Z

[justin-schroeder]

Yes, a big difference between tempo and other date libraries is that the tokens are locale aware. So if you want to force a given locale you either need to set that as your system locale, or manually specify it per function call.

As for the .utc() from moment — the answer is yes and no. Moment uses a non native date object to store information like timezone offsets. Tempo, by contrast, only uses native Date objects. You can choose to view this as a positive or a negative, personally, I greatly prefer it because it helps clarify what is actually occurring with date manipulation, and allows us to keep bundle sizes much smaller.

So — how do you mark something as UTC in tempo? Well you don’t really, all native Date objects are essentially just UTC timestamps (when you console log them or interact with their methods they always show localized values for that underlying timestamp). Instead, tempo lets you create that date object (utc timestamp) by specifying the time in a given location. So yes, if you want to create the utc time, in utc you can do tzDate('2020-02-04', 'utc'), but you can also do tzDate('2020-02-04T09:30', 'America/New_York') which would return a Date object (utc timestamp) for 9:30am on Feb 4th, 2020 in new york.

Hope that helps

[ghiscoding]

So yes, if you want to create the utc time, in utc you can do tzDate('2020-02-04', 'utc'), but you can also do tzDate('2020-02-04T09:30', 'America/New_York') which would return a Date object (utc timestamp) for 9:30am on Feb 4th, 2020 in new york.

Yeah in my case, I'll go with the first option since I use it in a datagrid open source project and I have no clue what TZ the user is in, so the utc option in tzDate() is great for that.

On a side note, I tried many times to migrate away from MomentJS (I tried DayJS, date-fns, Luxon)... but Tempo was the only one that really worked out of the box. The parse/format is really important in a datagrid and Tempo works amazingly well and since you guys have the same token as MomentJS, it was easy to migrate... oh and the fact that you provide an ESM build is just the cherry on top 🍒

Thanks for the great lib, I think I can close the issue since you answered all my questions. A big thanks