Live data from Hacker News

Europe pushing for lunar time zone

apnews.com

221–230 of 406 posts

Re: Europe pushing for lunar time zone

#221

Earlier quoted context omitted.

Yeah, I hate timezones with a passion but the more I think about them, the more I recognize they're the least bad option available. They correctly optimize for making most common cases trivial, while rare cases relatively easy. I think it needs to be said here: cross-timezone scheduling and datetime math are extremely rare relative to people's daily experience. It may not be obvious to us here, because we're much mor…

The worst problem with timezones IMO is that they are way too big [1], compared to what they should be if the world were equally divided into 24 hour "strips". Europe for example has CET which stretches all the way west to Spain, despite UTC+1 ending somewhere along the French-German border - so Spain and France are 1 hour "ahead" despite not needing to. [1] https://www.timeanddate.com/time/map/

I'd say that the biggest problem with time zones is that most people confuse them with time offsets (which unfortunately is what you are doing). A time zone is a geographical area. That area can run on different time offsets - "times". So the UK runs on UTC in winter, and UTC+1 in summer. It's wrong to think of the UK as being in the "UTC time zone".

This may seem pedantic, but the confusion causes real problems with software.

Re: Europe pushing for lunar time zone

#222
post #39

Earlier quoted context omitted.

With timezones: * I want to call my friend in Germany. What time is it for her? I guess I'm UTC-7 and she's UTC+1, so she's 8 hours ahead of me. I know that everybody around the world typically wakes up between 6 and 9 AM and goes to sleep between 8 PM and midnight, and she's an early bird, so she should be awake. * They said the meeting was going to be at 8 o'clock, but they are in a different time zone, did they me…

This is obviously a software problem that could be solved universally at the OS level. We have all kinds of low-level protocols for coordinating all manner of things. Distilling a coherent system of agreeing on a timezone difference, between two communicating entities and presenting that to the user at any time would be quite basic. We have location data for all, at all times. We have a local, accurate clock. There's…

Apple already do have support for specifying the time zone in appointment times, and the Clock application can show the current time in different places. What woudl you want to add to this?

Re: Europe pushing for lunar time zone

#223

I am a proponent of a Martian timekeeping system where each day has 24 hours 39 minutes and 35.244 seconds and all the rest of time units have standard lengths. For example, at midnight your martian clock would show the time as 24:39:35 for a fraction of a second, then wound back to 00:00:00. The calendar then would track the Earth calendar as close as possible, with shortened months to accommodate for the longer day…

> The calendar then would track the Earth calendar as close as possible, with shortened months to accommodate for the longer days. Why bother with months? Why not just count weeks? You could use something like the ISO 8601 week calendar – the year is divided into weeks. Weeks run Monday (1) to Sunday (7). Every year beings on a Monday – ISO 8601 has two years, the Gregorian year (starts on 1 January) and the ISO week…

> You could use something like the ISO 8601 week calendar – the year is divided into weeks.

Note that ISO 8601 weeks can be non-intuitive: per the Gregorian calendar, December 30, 2019, was in 2019; but per ISO 8601, December 30 it was in Week 1 Year 2020. Tom Scott:

* https://www.youtube.com/watch?v=D3jxx8Yyw1c

Re: Europe pushing for lunar time zone

#224
post #106

Earlier quoted context omitted.

I was so convinced .beats would take over the world (or solar system in this case). I had their watch, I installed their task-bar clock plugin for Windows 98, I harped on about it to my friends... a surprising number of which actually agreed it was a good idea. Then it just kinda fizzled out. I'm still upset it didn't take off.

It didn’t work in 1793 when it was mandated by the Convention despite the rest of the metric system taking roots. It was unlikely that a rebrand by a greedy Swiss corporation would make it more popular. Plus, current time keeping already use superior base systems. 12 and 60 are both highly composite numbers. Using a decimal system would be a step back. I wish we had symbols for 10 and 11 however.

[deleted]

Re: Europe pushing for lunar time zone

#225
post #175

Earlier quoted context omitted.

12 and 60 just introduce more special cases, exactly because they have so many divisors. Prime numbers have no non-trivial divisors. So more fractions get handled by the general case, the case of infinitely repeated digits. > 12 and 60 are both optimal cases for what you are describing. Optimal in what sense? They are certainly more convenient. I was describing mathematical elegance.

> Prime numbers have no non-trivial divisors. So more fractions get handled by the general case, the case of infinitely repeated digits. I don’t understand what you mean by special cases and general cases. R\Q is dense in R so most numbers can’t be written as repeating digits at all whatever the base you are using and in every bases all numbers which have a finite representation also have a repeating one by subtracti…

[deleted]

Re: Europe pushing for lunar time zone

#226
post #88
post #40

Earlier quoted context omitted.

I’m with you on the last two but a life without timezones sounds horrible. So many issues, like having to relearn the clock when you are in another timezone. I’ll meet you for lunch at 06.00! Life is based around the sun. Having some sort of agreed upon world timezone would be neat though, whether that was GMT or something less euro centric. So everyone would understand “we have a zoom meeting at 11.00 WT” instead of…

UTC is nice not because it is euro centric, but because there is a lot of sea on the opposite side of GMT and therefore it is pretty easy to place the date change line. There are multi-timezone countries on both sides of the oceans (USA, Russia, and the European Union basically counts as a third) so the date change line has to stay on the sea. There is only one good alternative, which would be to place the date chang…

I wonder which side Greenland, Iceland and the Falkland Islands would pick.

Re: Europe pushing for lunar time zone

#227
post #175

Earlier quoted context omitted.

12 and 60 just introduce more special cases, exactly because they have so many divisors. Prime numbers have no non-trivial divisors. So more fractions get handled by the general case, the case of infinitely repeated digits. > 12 and 60 are both optimal cases for what you are describing. Optimal in what sense? They are certainly more convenient. I was describing mathematical elegance.

> Prime numbers have no non-trivial divisors. So more fractions get handled by the general case, the case of infinitely repeated digits. I don’t understand what you mean by special cases and general cases. R\Q is dense in R so most numbers can’t be written as repeating digits at all whatever the base you are using and in every bases all numbers which have a finite representation also have a repeating one by subtracti…

I am not talking about numbers in R. I am talking about representing numbers from Q in a decimal fraction. (Or in a fraction to basis 11 or 12 or 60 etc.)

(I'm not sure why anyone would want to bring up R? Why R and not eg p-adic numbers? Or algebraic numbers?)

General case: your fraction p/q will be expressed as some repeating decimal fraction, like 22/7 = 3.|142857 (where | marks the start of the repeat.)

Special case: your fraction p/q will be expressed by a decimal fraction that stops. Like 2/5 = 0.4 or so.

You can't get rid of the general case. No matter what base you pick, the representation of the vast majority of your fractions will have infinite repeats.

You can however minimize the occurrences of the special case by picking a base with fewer divisors.

In contrast, picking a base with more divisors, like 12 or 60 gives you more special cases to worry about.

(And yes, you can apply the trick you suggested, to sort of remove the special case by writing 0.4 as 0.3|9. Or for that matter as 0.4|0; but I'm not sure that last one buys you anything.)

Just to be clear: this is all a bit tongue in cheek and just talking about what system is mathematically more elegant, by having fewer special cases. In practice, having more divisors is convenient; though in practice just rounding after some number of digits is also fine.

Re: Europe pushing for lunar time zone

#228
post #4

For some reason I thought this was going to be about an alternative to daylight savings time and any suggestion of abolishing that always gets my interest. It's not though, it's about giving the moon its own time zone. Which is about that least exciting moon based news I've ever heard although I'm sure there's interesting technical challenges (which I sincerely hope I never have to deal with).

> For some reason I thought this was going to be about an alternative to daylight savings time

I think I know the reason:

> and any suggestion of abolishing that always gets my interest.

When I read the title, I thought the same as you. It caught my interest because it sounded nonsensical so I was excited to see the reasoning and merits (or lack thereof) of the approach.

Re: Europe pushing for lunar time zone

#230

I am a proponent of a Martian timekeeping system where each day has 24 hours 39 minutes and 35.244 seconds and all the rest of time units have standard lengths. For example, at midnight your martian clock would show the time as 24:39:35 for a fraction of a second, then wound back to 00:00:00. The calendar then would track the Earth calendar as close as possible, with shortened months to accommodate for the longer day…

> each day has 24 hours 39 minutes and 35.244 seconds

> at midnight your martian clock would show the time as 24:39:35 for a fraction of a second

A similar idea could be to have exactly 24h 39min 35s each day (i.e. the last second before midnight is 24:39:34), then add a leap second every 4 days to compensate for the missing 0.244s, then skip it when the 0.006s errors cumulate up to 1s.

This just because in my opinion it is easier to live with leap seconds than with non-integer seconds.

Post reply on HN