696

Template

Further reading: RFC 3339 / ISO 8601

top 50 comments
sorted by: hot top controversial new old
[-] ByteJunk@lemmy.world 60 points 4 months ago* (last edited 4 months ago)

It should be implemented in people's brains.

How this goes, usually, is:

Them:...before 6PM.

Me: 6PM... Ours? The server's? The user's?

Them: GMT, of course.

Me: So that's 7PM London right now, and changes to 6PM in November?

Them: What no are you stupid. Always 6PM GMT.

Me:* jumps off a cliff*

[-] mox@lemmy.sdf.org 23 points 4 months ago

Them: GMT, of course.

Me: So that’s 7PM London right now, and changes to 6PM in November?

Them: What no are you stupid. Always 6PM GMT.

Me:* jumps off a cliff*

Sorry, but are you under the impression that GMT means London time, or that it observes British Summer Time?

[-] my_hat_stinks@programming.dev 14 points 4 months ago

UK is under BST (UTC+1) for half the year but people are usually just taught that the UK is GMT (UTC+0) which is based in the time in Greenwich, withought mentioning DST. I suppose it's also possible everyone is taught BST and just forgets about it because daylight savings sucks, but either way most people seem to think GMT and UK time are the same thing.

This means you'll get people asking for GMT times when they want BST or UK local time.

[-] nyctre@lemmy.world 6 points 4 months ago

Can confirm. Thought UK was always gmt+0, Paris/Amsterdam/whatever GMT+1, etc. (thought it was the clock that changed, not the timezone, if you know what I mean)

[-] caden@lemmy.sdf.org 3 points 4 months ago

I too was similarly confused by the original comment at first, but I think they're referring to the fact that 6pm GMT is 7pm in London during the summer (BST), and 6pm in London the rest of the year. It seems OP and "them" are both correct in that hypothetical exchange.

load more comments (1 replies)
[-] Klear@lemmy.world 16 points 4 months ago

Reminds me of a LARP I was on one time. A group of people I was doing stuff with ended up always meeting at 10 because we redefined "10" to mean "whenever we all meet".

[-] jaybone@lemmy.world 8 points 4 months ago

Don’t get it. Is this implying GMT has daylight savings?

[-] Ephera@lemmy.ml 9 points 4 months ago

GMT doesn't have daylight savings, but most people won't be as precise in language. Here in Germany, we might also tell people "GMT+2", even though it changes to GMT+1 in winter. Like, I don't even know what the correct shorthand would be for our timezone...

[-] abcd@feddit.org 7 points 4 months ago
load more comments (3 replies)
load more comments (1 replies)
[-] apprehentice@lemmy.enchanted.social 52 points 4 months ago

When the API returns UTC, but the system insists on giving you local time... but there's an extension method that accepts DateTimeOffset?

[-] agressivelyPassive@feddit.de 12 points 4 months ago

Or requires a timestamp with zone offset, but ignores the zone offset, so you have to send the timestamp itself with a zone offset of zero relative to the systems timezone, but can't just omit the zone offset, because it's required.

[-] bleistift2@sopuli.xyz 8 points 4 months ago

When the API returns UTC, but mandates that you give it an offset which it will add or subtract from the UTC time, while still adding the Z at the end.

[-] carrylex@lemmy.world 35 points 4 months ago

So just for additional context:

This meme was brought to you by the following API response scheme:

{
  "time": "2007-12-24 18:12",
  "servertimezone": "Europe/Vienna",
  "timezoneoffset": -8
}

when it could have just been

{
  "date": "2007-12-24T18:21:00-07:00"
}
[-] gjoel@programming.dev 8 points 4 months ago

To be fair, returning the actual timezone (as defined by tz.db) is useful if you don't just want the current time since you'll be able to take DST into account. Not sure how Vienna is -8 though, it should be +1 (or 2 depending on DST).

[-] el_abuelo@lemmy.ml 6 points 4 months ago

Your comment is a full throated endorsement of just working in UTC up until the presentation layer. Whether you intended that or not is another question.

load more comments (5 replies)
[-] carrylex@lemmy.world 3 points 4 months ago* (last edited 4 months ago)

Just for further clarification, the API works like this:

  • time is the local (client) time (in this case UTC-7)
  • servertimezone is the time zone where the server is located
  • timezoneoffset is the offset of the local time relative to the servertimezone (offset from the servers PoV)

To get the UTC date you have to do something like this:

time.minusHours(timezoneoffset).atZone(servertimezone).toUTC()
load more comments (1 replies)
[-] CodeBlooded@programming.dev 29 points 4 months ago

Mandating UTC everywhere and eliminating the concept of time zones altogether is all a political candidate needs to do in order to earn my vote in 2024.

Seriously, what is the point of time zones? The only explanation I’ve ever heard is “well if we didn’t have time zones, half the world would be expected to be awake when it’s dark out!” No. We could all just literally adjust the times of our business operations based around when daylight is usual for the different geographic regions as they have the sun shine on them. The physical “zones” of time zones could remain the same, and in those zones “noon” would just mean something other than “12:00.” “Noon” for one region could be 2300 while what is considered “noon” for another region could be 1800.

(And for my next rant: why the 24 hour clock is superior to the 12 hour clock… reason number 1? There’s 24 hours in a day…)

[-] DudeDudenson@lemmings.world 30 points 4 months ago

What you're proposing is literally time zones but without shifting the actual clock, you still end up with all the issues and you remove the link between the hour of day and the sun's position for people lol

Plus who gets to decide that everyone switches over and what is the new global time?

[-] CodeBlooded@programming.dev 3 points 4 months ago

Yes, this is literally what I’m proposing.

You do not still end up with the same issues. Somebody booking a ticket for a hotel room to be available at 1300 from a different time zone than said hotel will not arrive at the hotel to learn that the check in time is different from their expectation.

Regarding “the link between the hour of the day and the sun’s position,” I’m asserting that we should recalibrate this expectation based on time zones, rather than changing the clock to some fictitious time based on “noon” always equaling “1200.”

who gets to decide that everyone switches over and what is the new global time?

“Global time” in this context is already decided to be UTC. And no one gets to decide on the switch. This is a dream that will never come to fruition. 😕

Haha, let's inconvenience 99.9% of humans so some programmers have a slightly easier life. I've had my share of frustration with time zones, but this change is so enormous, that it's in no way appropriate.

load more comments (3 replies)
[-] netizen@programming.dev 5 points 4 months ago

You're saying that in the U.S. you enter your office on Monday and exit on Tuesday?

load more comments (1 replies)
[-] palordrolap@kbin.run 24 points 4 months ago

Implementing such a change has another problem: Who gets to have the time-zone that's noon at noon?

Are we going to let the British continue to get away with it? Even the excuse of "that's the way it has to be to keep things simple" would cause the French to revolt. Again. They still don't like to talk about the fact that it's Greenwich and not Paris that's the prime meridian.

Swatch's "Internet time" was a decimal system designed to mitigate the problem because no-one would have any idea what the old time was supposed to be, but people are used to the base-60 system. It didn't and won't catch on.

And it doesn't fix the "0 isn't my midnight" problem, which is pretty close to the original.

It also doesn't fix the "what time of day is it elsewhere in the world" problem, which still requires knowledge of time differences. You know. Time zones.

[-] roguetrick@lemmy.world 6 points 4 months ago

Decimal is bad anyway. We should first convert all our math to duodecimal.

[-] palordrolap@kbin.run 8 points 4 months ago

"What time is it, Mother?" "It is 7XƐ, child. Eat your breakfast."

load more comments (2 replies)
[-] bitchkat@lemmy.world 5 points 4 months ago

the correct time zone is UTC not Greenwich Mean Time.

load more comments (4 replies)
load more comments (5 replies)
[-] psud@aussie.zone 18 points 4 months ago

So organising a meeting for 03:30 has the problem of that not being working hours for some people, and you have to look up what working hours are in each area. What problem is that supposed to solve?

[-] MajorHavoc@programming.dev 15 points 4 months ago

you have to look up what working hours are in each area

It's common courtesy do this anyway...

[-] CoggyMcFee@lemmy.world 12 points 4 months ago

Instead of store hours like this:

  • Monday 6:00-18:00
  • Tuesday 6:00-18:00
  • Wednesday 8:00-18:00
  • Thursday 6:00-18:00
  • Friday 6:00-18:00

We can have store hours like this:

  • Sunday 22:00-Monday 10:00
  • Monday 22:00-Tuesday 10:00
  • Wednesday 0:00-10:00
  • Wednesday 22:00-Thursday 10:00
  • Thursday 22:00- Friday 10:00

Boy, I would love to live in a place where store hours would be like this. So convenient.

And I’d love to have the change in the day be sometime in the middle of the day so that “see you tomorrow” means sometime later in the day. Or maybe different areas would use different conventions to refer to the time when the sun is out and most people are doing things and the time when most people are asleep.

It would also be so pleasant and relaxing to visit a new country and constantly have to calculate the country’s time offset in my head. There would probably be an app on my phone that I would constantly look at that would convert the time where I am to the equivalent time I am used to. I won’t have a sense of when meals are or when I should expect stores to be open, or when it’s reasonable to wake up without converting to the time I’m used to. Some might say the thing I’m used to is my time “zone”.

It would also be great for TV shows and books to always run into issues when talking about the time because there’s no universal reference.

Even the actual convenience of scheduling a meeting with people in different parts of the world has issues. Now, you know that whatever time you say is the time for all people. But instead of being able to just look up each person’s time zone and see “oh, it would be 3am there, so they’d be asleep”, you’d have to go to some website that tells you what time most people sleep or what time most people eat meals, or whatever, and see by how many hours it differs.

load more comments (1 replies)
load more comments (1 replies)
[-] douglasg14b@programming.dev 28 points 4 months ago
[-] ooterness@lemmy.world 9 points 4 months ago

UTC is better than most, but leap seconds are still awful. Computers should use GPS or TAI everywhere. Dealing with time zones and leap seconds is for human readability and display purposes only.

[-] jerkface@lemmy.ca 11 points 4 months ago

That's why I only ever use Seconds Since Epoch.

[-] akincisor@sh.itjust.works 23 points 4 months ago

There is one big caveat to universal time:

Future dates: If you use utc here and a time zone definition changes, you're boned. You have to store local time and offset for just this one usecase.

[-] Natanael@slrpnk.net 16 points 4 months ago

Store absolute time in something like Epoch (seconds since 1970-01-01) plus local time zone

[-] BatmanAoD@programming.dev 5 points 4 months ago

Sorry, why would you be "boned" if you have UTC time? Are you thinking of the case where the desired behavior is to preserve the local time, rather than the absolute time?

load more comments (2 replies)
[-] carrylex@lemmy.world 4 points 4 months ago

If you use utc here and a time zone definition changes, you’re boned

I'm pretty sure that things like the tz database exist exactly for such a case.

load more comments (1 replies)
load more comments (2 replies)
[-] GTG3000@programming.dev 20 points 4 months ago

Anything an API returns should just look like 1720533944.963659 .

There's no reason to store dates as anything other than UTC. User-side, sure, timezones are useful. Server doesn't have to know.

[-] Zagorath@aussie.zone 17 points 4 months ago* (last edited 4 months ago)

This is absolutely fundamentally wrong. What you've described is what Nodatime calls an Instant, and it's a very important data class, but there are valid reasons to use other classes.

A LocalDateTime cares about the date and time locally. An event scheduled for 8am every Monday might use this. It would update accordingly if you move locations to a new locale.

A ZonedDateTime can almost be directly translated into an Instant, except that one time zone might change. If you go into or out of daylight saving time, or your region decides to change its time offset. Oslo time is still Oslo time. You use this if your event occurs at a specific time in a specific location.

An OffsetDateTime is like a ZonedDateTime, but instead of being tied to a specific time zone (e.g. "Oslo time") it's tied to a specific UTC offset (e.g. UTC+1).

You don't have to use Nodatime, but you should at least think deeply about what your time objects actually represent and what is the best way to represent them.

See the creator of Nodatime's presentation about thinking deeply about time for more.

load more comments (1 replies)
[-] muntedcrocodile@lemm.ee 13 points 4 months ago
[-] carrylex@lemmy.world 4 points 4 months ago

Well if it's a 32bit timestamp you're screwed after 19 January 2038 (at 03:14:07 UTC)

[-] PlexSheep@infosec.pub 8 points 4 months ago

I don't think modern systems use 32bit stamps anymore, the ones that do are built to fail

load more comments (1 replies)
load more comments (1 replies)
[-] ik5pvx@lemmy.world 12 points 4 months ago

There's an even worse thing: timezone selection UIs that don't let you choose UTC

[-] magic_lobster_party@kbin.run 6 points 4 months ago

Go:

01/02 03:04:05PM '06 -0700

[-] expr@programming.dev 6 points 4 months ago

Why in the ever-loving fuck would it do that? My hatred of Go only continues to grow.

[-] Ephera@lemmy.ml 6 points 4 months ago

Is '06 the year? What in the crime against humanity...

[-] MonkderDritte@feddit.de 6 points 4 months ago

Then the desktop reads it and does it's own thing with it.

[-] mox@lemmy.sdf.org 5 points 4 months ago

Wait til you see what's required to parse HTTP-date fields.

RFC 9110

load more comments
view more: next ›
this post was submitted on 08 Jul 2024
696 points (98.5% liked)

Programmer Humor

19623 readers
1 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS