[HN Gopher] Australia/Lord_Howe is the weirdest timezone
___________________________________________________________________
Australia/Lord_Howe is the weirdest timezone
Author : noleary
Score : 913 points
Date : 2024-10-30 06:21 UTC (16 hours ago)
(HTM) web link (ssoready.com)
(TXT) w3m dump (ssoready.com)
| surfingdino wrote:
| I love time/date problems. One of the best references on the
| subject of calendars is "Standard C Date/Time Library:
| Programming the World's Calendars and Clocks" by Lance Latham. He
| really goes into a lot of detail on various calendaring systems,
| some really cooky, https://amzn.to/4hjv5L3
|
| BTW. A long, informative post without a single mention of AI. A
| rare thing these days.
| notachatbot123 wrote:
| Clean link without affiliate code:
| https://www.amazon.co.uk/Standard-Date-Time-Library-Programm...
| spockz wrote:
| I really love this way of writing. Informational with occasional
| bits of humor. It makes it read and ingest.
| Semaphor wrote:
| Agreed, and the humor is restrained. Often there are posts
| (which tend to also have an annoying amount of gifs) which just
| overdo it. But here it's neatly used to lighten the writing.
| ides_dev wrote:
| Absolutely agreed, it's a really nice conversational tone. It
| is technical without being dry and entertaining without
| watering down the information. I strive to write like this.
| jccalhoun wrote:
| I guess I'm alone. I HATED it.
| ucarion wrote:
| You should read Matt Levine's Money Stuff! I think his is the
| tone I roughly was going for here.
| benreesman wrote:
| So this is a thing: I caught the Snake emoji behaving differently
| in some code because it was coded one thing before #celebrity-
| thing, and the opposite months later.
|
| Snake Emoji Kanye vibes are the weirdest timezone.
| pests wrote:
| Wait, how is it different before/after?
| captn3m0 wrote:
| The tz-iana mailing list is a lot of fun to subscribe to.
| Terr_ wrote:
| To me, one of the key framing ideas that almost all dates/times
| are actually _a set of matching-rules_ that you are monitoring
| for. You can _guess_ how many seconds will elapse until the match
| triggers, but you can 't be _totally_ sure [0] until it happens,
| and in some cases it will never quite happen at all. [1]
|
| Then the second half is often to reverse your "I think it will
| happen X seconds from now" delta-guess into "I'm also guessing
| that _your_ timezone 's clocks will say Y when it happens."
|
| Just don't forget to keep track of which timezones is
| _controlling_ the event versus which timezones it is being
| _displayed_ in. ____
|
| [1] Your UTC estimate might occur plus or minus leap seconds. TAI
| is safer, unless somebody discovers something exciting and new
| that changes the behavior of cesium atoms.
|
| [0] Such as if the time zone vanishes because the country is
| gone. Or perhaps the 1:30 to 2:00 thing couldn't exactly happen
| because the clocks went forward from 1:00 to 2:00 with a missing
| hour.
| ryzvonusef wrote:
| Reminds me of when Tom Scott descended into madness at trying to
| account for time zones:
|
| https://www.youtube.com/watch?v=-5wpm-gesOY
| luoc wrote:
| Somehow I end up watching this about twice a year
| import wrote:
| Nice morning reading
| prmoustache wrote:
| In my opinion, the best way to see it is not to pretend their are
| weird timezones.
|
| It is not because most of the world do summer time and that when
| they do they have a 1h transitions that we should take it for
| granted.
|
| This article do not mention the Chatham Standard Time Zone from
| Chatham Islands archipelago in NZ which is 45 minutes ahead of
| New Zealand Daylight Time, nor the Central Western Standard Time
| (Australia/Eucla). Also wikipedia mention there is a "train
| timezone" for the Indian Pacific train. I wonder if other trains
| have a dedicated timezone?
| sakjur wrote:
| > I wonder if other trains have a dedicated timezone?
|
| They used to, railway time is how our timezone system came to
| be.
| reisse wrote:
| > It is not because most of the world do summer time
|
| Eh? Most of the world don't do summer time.
| prmoustache wrote:
| Yes for some reason I read the following sentence backwards
| thinking that 410 timezones were observing DST while 185 did
| not.
|
| > Hmm. 410 timezones just don't DST at all. 185 have a
| 3600-second, i.e. 1-hour, difference.
|
| My point stands that there is no normality, just governments
| taking different decisions and being entitled to it and what
| the majority does is not relevant.
| ComputerGuru wrote:
| Is that also true by population?
| angrygoat wrote:
| The great thing about Australia/Eucla is that it's not
| officially gazetted, and yet there are road signs informing
| travellers about it. I love that people just do it and everyone
| goes along
| ucarion wrote:
| I mention Asia/Kathmandu instead of Pacific/Chatham or
| Australia/Eucla mostly because it's not one of those "exotic
| birds / kangaroos outnumber humans 5:1" kinds of places.
| lifthrasiir wrote:
| > These time zones have hundreds of hard-coded transitions out
| into the future. I don't understand why, it's not like they all
| have lunar calendar stuff going on.
|
| Without any additional update to the tz database, all annual
| transitions are assumed to continue indefinitely. So TZif version
| 1 would repeat transitions up to January 2038 (i.e. the end of
| signed 32-bit time_t), while version 2 or later would keep them
| for the compatibility (see the section 4 of RFC 8536) but also
| include the algorithmic description in the footer for later
| dates.
| radekk wrote:
| I wonder why the dst transition hours are encoded in local time.
| Wouldn't it be easier to do it in UTC? There is no need to
| differentiate between the same hour before and after change then.
| winternewt wrote:
| Perhaps to decouple DST transition rules from other time-zone
| changes. So if the time-zone offset is adjusted for some other
| reason then the DST rule does not also need to be changed.
| taneliv wrote:
| Suppose in local time (which is, say, UTC+3) the DST transition
| is on something like "last Sunday of 10th month at 02:00",
| which might then in UTC become "last Saturday of 10th month at
| 23:00, except if that Saturday is the last day of the month,
| then the second to last Saturday". In effect, if conversion to
| UTC causes the transition to move to a different day, it might
| also be on a different week or month, causing headache.
|
| (Or did you ask something else entirely? It wouldn't be the
| first time I misunderstood things about time zones.)
| Scarblac wrote:
| I'm going to steal "Greenland is part of the greater EU cinematic
| universe".
| guidedlight wrote:
| Nah, the weirdest time zone is Africa/Addis_Ababa, which nobody
| in Ethiopia follows.
|
| Instead the locals offset the time by 6 hours. So the AM cycle
| starts at dawn (i.e. 6am), and the PM cycle starts at dusk (i.e.
| 6pm).
|
| https://en.wikipedia.org/wiki/Time_in_Ethiopia
| squiggleblaz wrote:
| Sounds like it could be a candidate. Any system which can't be
| expressed in standard software is stranger than every system
| that can be.
| dpassens wrote:
| But whether standard software is able to express this system
| is up to the software, not the system, no? Why is this way of
| timekeeping weird, apart from the arbitrary decision not to
| support it?
| tankenmate wrote:
| The decision to not support it isn't "arbitrary" per se;
| it's a function of utility vs cost to implement (which a
| healthy dose of fudge). "Standard software" for timekeeping
| is far more useful precisely _because_ it is used by far
| more people.
| dpassens wrote:
| Maybe arbitrary was the wrong word. I understand that
| this is an implementation cost issue and I'm not saying
| that the decision not to pay this cost wasn't reasonable.
| My objection is not with tzdb, but with the
| characterisation of a real-life practice as weird just
| because software doesn't accommodate it. Shouldn't what
| people do be the reference for what is normal, rather
| than the rules encoded in software?
| lazide wrote:
| Software doesn't accomodate it because it's weird
| _relative to literally the rest of the world_.
| dpassens wrote:
| Sure. But that's completely different from saying it's
| strange because software doesn't accommodate it.
| lazide wrote:
| Is it?
| dpassens wrote:
| Yes, it is, because in your phrasing the fact that nobody
| else keeps time that way is the cause and lack of support
| in software the effect. The comment that I originally
| responded to is phrased as though lack of software
| support is the cause of weirdness.
|
| I object to the latter since software is not the source
| of truth, the social practices it aims to encode are. It
| is perfectly reasonable to say that this particular
| practice is so rare that it is out of scope, but this
| makes tzdb a not quite correct approximation of reality,
| rather than reality an approximation of tzdb.
| tsimionescu wrote:
| I would agree it's weird, but not because software doesn't
| support it, but because it's different from what the vast
| majority of the population of the world does. The fact that
| software doesn't support it is a downstream consequence of
| that.
| dpassens wrote:
| I agree with that take. It's also quite different from
| saying that it's weird because software doesn't support
| it, which is the claim I took issue with. Maybe I
| should've phrased my comment differently.
| Majromax wrote:
| Not necessarily. To be inexpressible in software, all it has
| to do is be unpredictable; it can still be boring.
|
| Let me define "local snoozing time" (LST): it's set to my
| local standard timezone as of today, but every time I hit the
| snooze button on my morning alarm it shifts 9 minutes
| backwards (the length of the snooze). By definition, I wake
| up at 8am in LST, regardless of what the world is doing.
|
| If the time shifts by more than one hour compared to the
| prevailing timezone, LST shifts forwards by a whole number of
| hours on Saturday morning, 2am LST to minimize that
| difference.
|
| This timezone is "boring" but uncomputable, since it depends
| on unpredictable events.
| Ekaros wrote:
| For country near equator that is not actually unreasonable
| system to define day cycle.
| rob74 wrote:
| Yeah, for countries further away from the equator this would
| be crazy. Actually I thought Ethiopia is already far enough
| from the equator to have significant changes of
| sunrise/sunset times, but according to
| https://www.timeanddate.com/sun/ethiopia/addis-ababa, they
| only vary by ~ 40 minutes over the year, so I guess that's
| close enough to "constant" for most of the population...
| kbbgl87 wrote:
| And they live 7 years in the past.
| guidedlight wrote:
| They do. So I guess the observed timezone is UTC-61314.
| Scarblac wrote:
| Probably depends on how many of those 7 were leap years at
| any point in time?
| AStonesThrow wrote:
| Ethiopian Christians have retained many Jewish customs compared
| to others, so you will also see them observing something like
| kosher diets. Although dusk is not sunset, it may be the case
| that they've adapted the cycle from Hebrew calendar observance.
| marginalia_nu wrote:
| That's very similar to how the romans conceived of time. Wonder
| if it's an old relic from when north africa was a bunch of
| provinces.
|
| https://en.wikipedia.org/wiki/Roman_timekeeping
| arethuza wrote:
| "An hour was defined as one twelfth of the daytime"
|
| That must have been fun for the Romans here in Scotland - an
| hour would be roughly two and a half time as long in winter
| as in summer!
| throw0101a wrote:
| > _That must have been fun for the Romans here in Scotland
| - an hour would be roughly two and a half time as long in
| winter as in summer!_
|
| Mechanical clocks in Japan were designed to handle those
| situations:
|
| > _Adapting the European clock designs to the needs of
| Japanese traditional timekeeping presented a challenge to
| Japanese clockmakers. Japanese traditional timekeeping
| practices required the use of unequal time units: six
| daytime units from local sunrise to local sunset, and six
| night-time units from sunset to sunrise._
|
| *
| https://en.wikipedia.org/wiki/Japanese_clock#Temporal_hours
| pbmonster wrote:
| Much less of an issue without clocks.
|
| Look where the sun is, remember where it is at sunrise/-set
| (much easier if you're outside every day) and then mentally
| divide the sky into segments and just ballpark it.
| arethuza wrote:
| "Look where the sun is"
|
| Well, maybe that was another problem with Scotland... ;-)
|
| No wonder they built a few walls and retreated south....
| Horffupolde wrote:
| That's standard traditional Hebrew time still today.
| ttepasse wrote:
| You'll find the ancient interpretation that the new day
| starts at sunset still in religions. Sabbath starts on Friday
| evening, Easter and Christmas day start on the eve of the day
| before. Possibly the Eids of Islam too, but I'm unsure.
|
| Ethiopia is one of the ancient Christian countries, the
| second of officially convert and the Ethiopian Ortodox Church
| still seems prominent. I assume that's the reason why.
| hprotagonist wrote:
| Ethiopian time keeping is peculiar all over.
|
| https://en.wikipedia.org/wiki/Ethiopian_calendar
|
| _The Ethiopian calendar has twelve months, all thirty days
| long, and five or six epagomenal days, which form a thirteenth
| month._
| hhdhdbdb wrote:
| That no odder than Gregorian
| charlieyu1 wrote:
| Still not weirder than Lunar calendar
| stronglikedan wrote:
| Why use celestial bodies at all? Let's bring the Soviet
| calendar back!
| hprotagonist wrote:
| something something every 5 years.
| IggleSniggle wrote:
| It's not odd as in a more unusual system, but odd in that
| it is widely incompatible with the calendar of most of the
| world, but still official calendar. Kinda like the Kodak
| calendar (which was instead 13 28-day months (364 days),
| and iirc does the off-day adjustments over the corporate
| winter holiday...actually pretty reasonable)
| pc86 wrote:
| Merry Corporate Winter Holiday!
| xeromal wrote:
| lmao
| antod wrote:
| Not reasonable at all... it's Corporate Summer Holiday
| around here.
| IggleSniggle wrote:
| You take that back!
| kergonath wrote:
| There are good reasons for the Gregorian calendar's
| oddities, though. Any simple system stops being simple when
| you apply it to enough different situations. I am not sure
| programmers would like it better if each country had a
| different calendar for each season. Because a day that
| starts at 6 and ends at 18 would make sense 2 days each
| years here in Europe. Not even that if you go far enough
| North.
| brodo wrote:
| That's similar to the Shire calendar system[1]. It has twelve
| months of 30 days, but the missing days are not in any month.
|
| 1: https://tolkiengateway.net/wiki/Shire_Calendar
| libraryofbabel wrote:
| And also similar to the French Revolutionary calendar (1793
| to 1805) which had twelve 30-day months and 5 or 6 _jours
| complementaires_.
|
| I like that Tolkien's legendarium got the first mention
| here though.
| rainingmonkey wrote:
| The ancient Roman calendar was before that, with 10
| months of 30 or 31 days and intercalated days when it's
| no month at all.
|
| Sometimes priests moved these days to suit political
| shenanigans.
|
| Caesar ended this madness and "rationalised" the system,
| coincidentally making his year-long consulship last for
| 446 days.
| prmph wrote:
| Wasn't Tolkien's LOTR partly inspired by Ethiopia?
| aquova wrote:
| I'm actually quite a fan of perennial calendars like that, I
| think the Ethiopian calendar is a much more logical system
| than the Gregorian system.
| ucarion wrote:
| Almost every calendar system has a similar trick:
| https://en.wikipedia.org/wiki/Intercalation_(timekeeping)
|
| The west inherits from the Romans, and Julius Caesar
| standardized away the Roman intercalary month by glomming it
| into Feburary. Before that a "priest" (the pontifex maximus)
| (in scare-quotes because it was a political office) would add
| that month on an ad-hoc basis. Not so different!
| wakahiu wrote:
| This is common across East Africa, including Kenya where I'm
| from. The night ends at 6:00AM, with 7:00AM being saa moja
| (first hour) of the day. Similarly, the day ends at 6:00PM
| (thenashara). Intuitively, this clock makes much more sense
| than the English clock. There's rarely confusion between times
| because it's embedded in the language.
| spuz wrote:
| What time is displayed on your phone when you are in Kenya?
| Is there a setting to make it display the commonly used time
| rather than the official time? I'm going to Kenya next year
| and I'm excited to see how my phone behaves.
| nine_k wrote:
| This is indeed a more logical clock, as it follows the
| natural cycle of activity. Equally, calendars that put the
| end of the year at the time after harvest ("autumn"), or at
| the start of agricultural work ("spring") are also more
| logical.
|
| Positioning the beginning of a new day at noon, and a new
| year t a solstice, is just a technical convenience, because
| these are easy to detect with very simple astronomy tools.
| nerdponx wrote:
| What makes it more logical? The wheel turns all the same no
| matter where you mark the beginning. In the Northern
| hemisphere, there's actually something nice about starting
| the year in the dead of winter: it feels like the year is
| born in the spring and then dies away the following winter,
| not unlike a lifetime.
| delecti wrote:
| > it feels like the year is born in the spring
|
| Then shouldn't the start of the year be when the year is
| "born"? Or alternatively, the end of the year when the
| year "dies"? January 1 is neither.
| jvanderbot wrote:
| The year "dies" on the longest, darkest nights. (Dec 21,
| technically). We mourn its passing and celebrate it's
| life with drinks. I'm guessing there was in antiquity, a
| whole bunch of dreadful and exciting parties in the last
| 10 days around the longest nights.
|
| It slowly grows after that and blooms later.
| maratc wrote:
| January 1 is so close to December 25 (when Jesus is
| believed to have been born) so if we wanted to count
| years since that -- and call it AD for "Anno Domini" (the
| Year of Our Lord) -- we could declare the year to begin
| on January 1st.
|
| Which is exactly what we did.
| quesera wrote:
| > _December 25 (when Jesus is believed to have been
| born)_
|
| I don't think anyone actually believes Jesus was born on
| Dec 25.
| xeromal wrote:
| March should be the 1st month then I'd think. I'm pretty
| sure that's how the roman calendar worked. War started in
| spring.
| athom wrote:
| If you DO start in March, your days/month fall into a
| neat little pattern:
|
| Mar 31 - Aug 31 - Jan 31
|
| Apr 30 - Sep 30 - Feb 28/29
|
| May 31 - Oct 31
|
| Jun 30 - Nov 30
|
| Jul 31 - Dec 31
|
| That highlights a few interesting cycles you can use to
| calculate dates from a simple count of days from the
| start of the year:
|
| 153 days every 5 months
|
| 61 days every 2
|
| 31 days per month
|
| An "early reset" occurs every second month, jumping to
| the next 2-month cycle after the second day 30. Another
| occurs after every fifth month, jumping into a new
| 2-month cycle halfway through the last one of the
| 5-month. And of course, end of the year breaks the third
| "5-month" cycle WAY early, just before even its first
| 2-month is finished.
|
| I won't try to detail the process of generating dates
| from this here, but I'm sure most of us here can work it
| out with just a little effort. Instead, here's a couple
| more fun facts to consider:
|
| If you DO start the calendar from March, counting it as
| month 1, September (7) through December (10) map rather
| nicely to their own numeric positions. That seems a
| pretty strong hint, to me.
|
| And I REALLY love this one:
|
| The Gregorian cycle consists of four centuries. The first
| three are 36,524 days each: 100 years x 365 days + 24
| days for the leap years. The hundredth year (ending in
| 00) is NOT considered a leap year, EXCEPT for every
| FOURTH hundredth. So that's 4 centuries * 36,524 days =
| 146,096, plus 1 more for the leap century, for 146,097.
|
| That number is EXACTLY divisible by 7, which means the
| week cycle repeats WITH the Gregorian one. Good thing!
| Otherwise, we'd have to wait 2800 years!
| madcaptenor wrote:
| Zeller's congruence for the day of the week
| (https://en.wikipedia.org/wiki/Zeller's_congruence)
| exploits this:
|
| - months are counted as 3, 4, 5, ..., 14, with 13 and 14
| being January and February of the following year
|
| - the contribution of the month to the day of the week is
| floor(2.6 * (m+1)) - the 2.6 comes from the 13 "extra"
| days (over the approximation 1 month = 4 weeks) in every
| 5 months.
| ComputerGuru wrote:
| If the year is "born in the spring" then surely you would
| want the year to start in the spring (if not the spring
| equinox, then March) and not winter?
| maratc wrote:
| Of course, and -- if you were Roman, for instance -- you
| could, for example, call the 8th month a name with "octo"
| (Latin for "eight") in it, or the 10th month something
| with "decem" (Latin for "ten").
| QuercusMax wrote:
| Positioning of the new year at the Equinox shouldn't be any
| harder than doing it at the solstice (since equinoxes are
| halfway between the solstices), and it makes much more
| sense IMO. First half of the year: more day than night.
| Second half of the year: more night than day.
| alserio wrote:
| didn't the julian/gregorian calendar started that way and
| drifted?
| krick wrote:
| Of course not. Gregorian Calendar didn't drift, it just
| fixed drift in Julian calendar, which was like a couple
| of weeks by 1582. And "new year" in Julian calendar was
| 1st of January, same as now. It was inherited from
| previous Roman tradition, because Romans already had the
| custom to mark 1st of January as a new year, because
| since 153 BCE it was the date when consuls were
| inaugurated. So it's an entirely political thing and
| makes no real sense whatsoever. We are celebrating the
| day of Roman consulate inauguration for more than 2000
| years now.
|
| And before that they they started years from 1st of
| March, which is much closer to one of the Equinoxes,
| which is what all sane people (including french
| revolutionaries) consider to be the proper start of a
| year.
| alserio wrote:
| very informative, thank you
| Y_Y wrote:
| Only if everyone is a peasant farmer with the same crops in
| the same place. My activities are barely related to the
| height of the sun in the sky, and like the other residents
| of my city I don't take a ton of notice of harvest time.
| Bus timetables and cultural festivals are a much bigger
| deal (of which one in particular is indeed historically
| related to a harvest).
| jvanderbot wrote:
| This "Day is 12 hours long" thing just doesn't work
| anywhere else.
|
| I live far from the equator - "Dawn" is sometimes after
| breakfast, and "Dusk" can happen before I get off work.
| jachee wrote:
| As former Alaska resident, can confirm. December sunrises
| are often after 10am, and sunsets before 4pm. Vice versa
| in summer.
|
| Then you get above the Arctic Circle, and there are days
| with neither. :D
| napoleongl wrote:
| My first thought as well as a swede. And coincidentally
| one of the things my old Kenyan classmate found the most
| strange about Sweden was the fact that the length of day
| was not even close to constant. That and when I explained
| to him that the sun being up doesn't necessarily mean
| warmer weather, in the winter it's practically takes the
| temperature further from zero as sun means no warming
| clouds...
| TremendousJudge wrote:
| Since it's pretty much on the Equator it makes a lot of sense
| to keep time like that -- days and nights have the same
| duration all year long. Such a system doesn't make sense for
| places that have wide variations between seasons, unless you
| also alter the length of the hours to match (which I think
| was done at some point somewhere in Europe, but I can't find
| any references)
| xvedejas wrote:
| Even on the equator, sunrise and sunset times will vary by
| +/-15 minutes, because solar days are not of equal length.
| But yeah, close enough for imprecise use.
|
| https://en.wikipedia.org/wiki/Equation_of_time
| Maxamillion96 wrote:
| Same with Somali. The first hour of daylight is hal saac
| (Hour 1)
|
| 7 AM is 1 Saac ( Hour 1)
|
| 6 PM is 12 Saac ( Hour 12)
|
| 7 PM is 1 Saac
|
| 6 AM is 12 Saac
| krick wrote:
| > 7 AM is 1 Saac
|
| > 7 PM is 1 Saac
|
| How do you distinguish AM/PM? How does one say that
| something will happen 19:00 specifically, and not 07:00?
| bloppe wrote:
| I would probably be a bit confused by the fact that 6pm is 13
| hours after 5pm, but I'm assuming Swahili has better ways of
| communicating time
| mbrubeck wrote:
| You already have to deal with the fact that 12pm is 13
| hours after 11pm.
| chgs wrote:
| Everyone I work with in Kenya uses standard dates and times.
| It's a requirement when you work internationally.
| tobyjsullivan wrote:
| Do they exclusively speak English as well?
| borski wrote:
| Many do, yes. And I'd suspect that's true for those the
| parent commenter works with _in particular_.
| samatman wrote:
| Intuitive is a synonym for "what one is used to", so I
| believe you when you say that according to your intuition,
| what you're accustomed to makes the most sense.
|
| In a place with considerable skew in daylight hours between
| the summer and the winter, this would be quite _unintuitive_
| , because daylight hours would become longer (and night hours
| shorter) during winter and spring, and the opposite for
| summer and autumn.
|
| Either that, or a fixed conventional notion of "dawn" which
| only corresponds to the sun rising around the Equinoxes.
| Either way would be unintuitive.
| ar_lan wrote:
| It's also incredibly condescending, at least the way they
| wrote it.
| technothrasher wrote:
| Traditional Japanese timekeeping kind of did both. The "am"
| and "pm" time periods started at midnight and noon, but the
| clocks themselves started at dawn. The hours counted down
| from hour 9 to hour 4 (they did not use 3-1). Each of the
| hours was approximately two modern hours, but their
| individual lengths changed every two weeks to keep the
| periods aligned with the sun. The twelve hours on the linear
| clock dials ran: 6,5,4,9,8,7,6,5,4,9,8,7 (and then a final 6
| to match the first six, since it was a linear instead of
| circular dial).
| helsinkiandrew wrote:
| Thats almost as confusing as the Nautical Day. Where a day on
| ship started at noon the "previous" day - with PM proceeding
| AM.
|
| https://en.wikipedia.org/wiki/Nautical_time#Nautical_day
| layer8 wrote:
| That's also how Julian days work, they go from noon to noon:
| https://en.wikipedia.org/wiki/Julian_day
| dudeinjapan wrote:
| Wow, this is great! This is exactly how Ive thought times
| should be done. Ive always called it "local sunrise time". All
| the advantages of DST without the biannual spikes in traffic
| fatalities.
| prmph wrote:
| Interesting. I propose that the transition between AM and PM
| should happen right in the human-sensible middle of the day. If
| most people start their daily activity around 6, and retire by
| by 10pm, then the middle would be 14hrs.
|
| This would also give a nice 3-part division to the day that
| matches their use: 1st 8 hours for the morning, next 8 hours
| for the afternoon, and the next 8 hours for evening/night.
| Currently, morning alone is 12 hours, and afternoon is like 6
| (or less) and the evening takes the rest.
|
| But I guess the current noon time is chosen for when the sun is
| highest in the sky, so maybe to preserve noon as the transition
| point, morning should start from 4:00 hrs, then the afternoon
| starts from 12:00 hours, and evening would start from 20:00
| hours.
| ucarion wrote:
| Japan does something similar in the context of things that
| close after midnight:
| https://en.wikipedia.org/wiki/Date_and_time_notation_in_Japa...
|
| FWIW, the English-speaking world used to switch years on March
| 25:
| https://en.wikipedia.org/wiki/Calendar_(New_Style)_Act_1750#...
|
| Neither of these are technically things that tzdb can even talk
| about. They're concerned with civil time, not calendars or
| other "reckoning" problems.
| squiggleblaz wrote:
| I kind of thing a half hour daylight savings difference instead
| of an hour is a pretty low bar for the weirdest timezone. Almost
| any of the others are weirder: Antarctica/Troll definitely sounds
| weirder. The Moroccan and Gazan timezones that can't be expressed
| by the system as it was written because at least that means that
| they have some different kind of a rule, even if lunar time is
| well known. Same with the ones that are in Apple's naughty list
| because they're transitions the day before some day - again, not
| very weird, but at least it's weird enough to break things.
|
| But I do agree with leap seconds: it's absolute trivia, not a
| useful thing for a programmer to know. Your computer smears them
| and you don't even know when they happened. You could completely
| forget them. Except that countries transitioned from ignoring
| leap seconds to considering them, so the switch in Australia from
| "GMT+x" to "UTC+x" a couple of decades ago was the transition
| from ignoring leap seconds to incorporating them. The fact that
| this is almost universally ignored is probably for the better.
| michaelt wrote:
| _> But I do agree with leap seconds: it 's absolute trivia, not
| a useful thing for a programmer to know._
|
| By and large, I agree with this.
|
| But I've always found it a bit funny when a large organisation
| [1] says "our servers have sub-millisecond timing accuracy,
| thanks to GPS synchronization and these PCIe rubidium atomic
| clock cards we've developed" while at the same time saying [2]
| "we smear leapseconds over the course of a day, in practice it
| doesn't matter if a server's time is off by +-0.5 seconds"
|
| [1] https://engineering.fb.com/2021/08/11/open-source/time-
| appli... [2] https://engineering.fb.com/2020/03/18/production-
| engineering...
| growse wrote:
| The thing that super accurate timestamps buys you is common
| agreement across _your infrastructure_ as to what the time
| is. This basically makes distributed systems work faster
| /better/whatever.
|
| The relation between that time and what the rest of the world
| thinks the time is is actually less relevant.
| knallfrosch wrote:
| And then you validate against Microsoft's default `ClockSkew`
| of 5 minutes.
| zokier wrote:
| I think the irony comes to full circle when you then use
| `unsmear` library to reverse the leap smearing in ntp
|
| https://github.com/google/unsmear
| zarzavat wrote:
| > even if lunar time is well known
|
| The date of Ramadan is not well known because it's based on
| being able to _see_ the moon from the local position on Earth.
| If the sky is particularly overcast for instance, then you
| cannot see the moon, regardless of where the moon is.
|
| This presents problems for implementation of the calendar into
| the workings of a nation state. Many countries that adopt the
| Islamic calendar officially use an approximation, a pre-
| calculated date based on the moon's predicted visibility at a
| particular position.
|
| The Islamic calendar is therefore not really one calendar, but
| two: the observational Islamic calendar and the predicted
| calendar, and both have a dependence on a location from which
| either real observations are made, or predicted observations
| are made.
|
| I don't know how Morocco or Gaza do it.
| pavel_lishin wrote:
| > _The date of Ramadan is not well known because it 's based
| on being able to see the moon from the local position on
| Earth._
|
| Note to self, look up what Islamic scholars think should be
| done about Ramadan on a moon base.
| umanwizard wrote:
| Not quite a moon base, but for Muslims on the ISS:
|
| > the Malaysian government called a gathering of 150
| Islamic legal scholars, scientists, and astronauts to
| create guidelines for Dr. Shukor. The scholars produced a
| fatwa, or non-binding Islamic legal opinion, intended to
| help future Muslim astronauts, which they translated into
| both Arabic and English. They wrote that in order to pray,
| Muslims in space should face Mecca if possible; but if not,
| they could face the Earth generally, or just face
| "wherever." To decide when to pray and fast during Ramadan,
| the scholars wrote, Muslims should follow the time zone of
| the place they left on Earth, which in Dr. Shukor's case
| was Kazakhstan. To prostrate during prayer in zero gravity,
| the scholars stated that the astronaut could make
| appropriate motions with their head, or simply imagine the
| common earthly motions.
|
| I'm not an Islamic scholar (or a Muslim at all), so this is
| just speculation, but my guess is that if it were a
| permanent settlement, with people being born and living
| their whole lives on the moon base (so "where they left
| earth from" is not meaningful), they'd probably just settle
| on one permanent Earth time zone to follow; presumably
| either that of Mecca, or that of whatever country on Earth
| (if any) owns the base.
| pavel_lishin wrote:
| Prayer and pointing to Mecca seems pretty simple on the
| moon - but if Ramadan is based on when you can see the
| moon, it seems that Ramadan would start as soon as the
| person in charge walks by a window.
| umanwizard wrote:
| Yep! I think for that case the "follow the time zone of
| some particular place on Earth" rule would apply.
| vikingerik wrote:
| Moon-dwelling Muslims would go by the phases of Earth, if
| they wanted to match Earth timing but not rely on
| communication with Earth. The Earth as seen from the Moon
| exhibits the opposite phase as the reverse. Ramadan would
| begin when the Moon-dweller sees the Earth as being just
| past full. If you wanted, you could synch it with a
| particular timezone on Earth, by watching for when that
| location on Earth (Mecca or whatever) just rotated past
| the terminator so it experienced sundown. (Of course none
| of this can be directly observed if you're on the far
| side.) (And I get your joke about seeing the moon when
| you're on it; this is the practical alternative.)
| Epa095 wrote:
| > But I do agree with leap seconds: it's absolute trivia, not a
| useful thing for a programmer to know.
|
| Maybe, all I know is that it was relevant for me during the
| first years in industry. If you work with timeseries which
| comes from source systems you don't 100% controll, like in many
| industrial settings, its important to know about them, and how
| they are handled upstream. Do the source do smearing, or does
| it just sync every X hours? Does it sync with NTP, which will
| smear (slew) the change, or have they implemented their own
| thing? Do they just run `ntpd -q` regularly?
|
| But yeah, as I type it out I realize that most programmers
| probably don't work in that domain:-p
| jiri wrote:
| Antarctica/Troll is not that weird. Really they use just two
| times: Cape Town time during short summer and Norway time
| otherwise. Unfortunately, Norway time happens to have DST ;-)
| jdietrich wrote:
| Leap seconds are generally trivia, but they become absolutely
| crucial in applications where multiple parties must be in exact
| agreement about chronology - the obvious example being
| financial transactions. A lot of markets were closed for the
| leap second and many banks still suspend all transactions
| during any change of local time to mitigate the risk of error.
|
| Even in applications where we don't particularly care, there
| have been a surprisingly large number of leap second-related
| bugs. CGPM have decided to abolish the leap second for good
| reason.
|
| https://en.wikipedia.org/wiki/Leap_second#Other_reported_sof...
| Tor3 wrote:
| And when processing satellite data.. if you're not in
| agreement of the time, that one second error results in a
| ~7km geographical error for your typical polar orbit weather
| satellite.
| Izkata wrote:
| > I kind of thing a half hour daylight savings difference
| instead of an hour is a pretty low bar for the weirdest
| timezone.
|
| Especially when, even disregarding the ones with special rules,
| there's a couple that are 45 minutes off.
| madcaptenor wrote:
| Came here looking for Troll - as far as I know it's the only
| one to have _winter_ daylight savings time. Also it gets extra
| points for the name.
| floitsch wrote:
| I implemented `DateTime` in Dart and Toit and wrote a blog post
| about the things I noticed:
| https://medium.com/@florian_32814/date-time-526a4f86badb
|
| Timezones are fun...
| trollied wrote:
| https://en.wikipedia.org/wiki/Sandringham_time was a crazy one
| fouronnes3 wrote:
| What I like about the tz database is that's it's technically a
| diff of a diff. It stores the difference across history, of the
| difference of each timezone with UTC. Right? So it's a diff^2.
| But! The tz database gets updates! So those commits are diffs of
| diffs of diffs, or diff^3.
|
| Can we go further? You bet! It has a changelog, and that
| changelog is stored in git, so commits to the tz changelog are
| diff^4: they are changes to the list of changes to the list of
| changes to the list of changes to UTC.
| dalmo3 wrote:
| You forgot that UTC (or timekeeping in general) itself is a
| diff.
| fouronnes3 wrote:
| Oh that's a great point! We have achieved diff^5 at last!
|
| Now that I think of it, we could even stretch it one more
| level. In practice UTC is "realized" as a "best of" diff to
| atomic clocks in labs around the world, which are themselves
| diff against a fixed time point, as you pointed out. So that
| realization technically changes when the official UTC
| bulletin[1] is published by BIPM. So diff^6!
|
| [1] https://www.bipm.org/en/time-metrology
| hhdhdbdb wrote:
| Can we bring relativity in for another diff :)
| flippyhead wrote:
| Yes, but, it's always 5 o'clock somewhere, amiriiight??
| Yossarrian22 wrote:
| Don't forget using GPS to get the time and tell you if
| you've crossed time zones
| gavindean90 wrote:
| So would that be diff ^ 10?
| Horffupolde wrote:
| A diff of a diff is just 2 diff. It's not a product of diffs.
| ninalanyon wrote:
| Spoilsport!
| Horffupolde wrote:
| Just be rigorous with your words.
| jiggawatts wrote:
| Oh wow, what a coincidence, I was _just_ looking at Lord Howe
| Island on a map of species conservation.
|
| For anyone who doesn't know: Lord Howe Island is the _last true
| paradise on Earth_.
|
| I went there on holidays a few years back based on two travel
| review recommendations. Both were by professional travellers that
| had been to pretty much everywhere, and both said it's the _best
| place they 've ever been_. The reasoning was that every other
| tropical island has "something" wrong with it. Pushy locals
| trying to sell you stuff, sharks in the water, malaria,
| pollution, crime, poverty, or _something_.
|
| Lord Howe is about as safe as it's possible to get, civilised
| beyond belief, pristine, unpolluted, etc...
|
| It's one of the last places in the world with undamaged,
| unbleached coral reefs in protected waters. The diving there is
| just unbelievable, more beautiful than any Planet Earth
| documentary you've seen.
|
| Birds nest on the beach, and you have to _step over them_ gently
| because there 's thousands of them and the juveniles can't fly
| yet.
|
| I met the police officer of the island and pointedly asked him
| when was the last time he had to deal with crime.
|
| "Crime... _crime_... let 's see." he said, counting on his
| fingers slowly "Umm... seven years ago there was a domestic
| violence report because a tourist slapped his wife in an
| argument."
|
| The hotel doors have no locks. There's $500 in cash in a tin next
| to a shack full of equipment on the beach with a "honesty system"
| rental price list sign next to it. The bloke selling you coke
| cans at the milk bar bought it with the $20 million he made in
| the stock market. Half the tourists go there by private plane.
| Ballmer's son took his super yacht there with a harem of models.
| And on, and on.
|
| If you ever get the opportunity to visit: GO!
| ascorbic wrote:
| > Half the tourists go there by private plane. Ballmer's son
| took his super yacht there with a harem of models.
|
| Sounds great apart from that bit.
| jiggawatts wrote:
| He's not there _all_ the time!
| djaychela wrote:
| Oddly was just reading something yesterday and it mentioned that
| in the UK there were years during the war where we had double DST
| for energy saving reasons. (although we went between 1 hour and 2
| hours, so it was only really a change compared to the norm)
|
| https://www.atlasobscura.com/articles/the-extreme-daylight-s...
| IshKebab wrote:
| I don't really understand how that would save energy. Did
| people work 7am-3pm days or something?
| f1shy wrote:
| It doesn't! That is why some countries want to leave one time
| for the whole year. When lots of power were used by lighting,
| it must have saved something...
| hnbad wrote:
| The idea behind DST is that it shifts working hours into
| daylight hours during the darker months. This would
| theoretically cut down on energy use for lighting during
| those hours.
|
| Of course offices, factories and even schools still use
| artificial lighting even during daylight hours. And now the
| energy use of artificial lighting is much lower than back
| when everything used filament.
| shultays wrote:
| Even ignoring the energy saving part, it sucks waking up
| and leaving for work or school while it is still dark.
|
| A while ago Turkey switched to a different timezone and
| stopped doing DST for reasons and now everyone was waking
| up one hour early in winters. Considering how bad traffic
| is in larger cities that meant a lot of people will be
| waking up and going to work or school while it is still
| dark.
| euroderf wrote:
| I thought the main idea behind it is (or used to be) that
| kids can go to and return from school in daylight.
| jdietrich wrote:
| Yesterday in the UK, sunrise was about 7am and sunset was
| about 4:40pm. Electricity demand peaked at about 5:30pm, in
| the overlap between workplaces closing for the evening and
| people returning home and turning everything on. There's a
| straightforward case for either staying on BST (UTC+1)
| throughout the year, or (as was the case during WWII) using
| UTC+2 during summer and UTC+1 during winter, effectively
| bringing the UK in line with CET/CEST.
|
| The key factor in the war was the blackout - street lighting
| was turned off for the duration and vehicle headlights were
| mostly covered over, to avoid providing easy targets for
| night bombing raids. This obviously hugely increased the
| hazards posed by the early sunsets under GMT.
|
| https://www.timeanddate.com/astronomy/uk
|
| https://www.energydashboard.co.uk/live
|
| https://www.bbc.co.uk/news/articles/c0mznrv3jvmo
| extraduder_ire wrote:
| I thing, more helpfully, that would better sync up UK time with
| time on much of the continent. Quite useful if you're doing a
| lot of things internationally.
| twelvechairs wrote:
| Along with Kathmandu for weird offsets is Australian Central
| Western Standard Time (UTC +8:45), used in a tiny area of
| Australia with the largest town being Eucla (population 37).
| Being mainly within Western Australia (which doesn't use daylight
| savings) but partially within South Australia (which does use
| daylight savings) there has also been informal use of UTC+9:45
|
| Historically there was also Dublin mean time (UTC -00:25.21) and
| Warsaw mean time (UTC+1:24)
| ajdlinux wrote:
| An interesting aspect of ACWST is that it has no legal status -
| it's observed purely by local convention, though it's still
| managed to make it into tzdata.
| antisol wrote:
| indeed! and not only is it in tzdata, there are signs on the
| road telling you about it
| LysPJ wrote:
| > America/Nuuk does daylight savings at -01:00 (yes, with a
| negative)
|
| Somewhat related: Europe/Dublin has a negative DST offset. Irish
| DST runs through the European winter (i.e. the opposite of the
| other European timezones).
|
| (More details here:
| https://github.com/golang/go/issues/56743#issuecomment-13157... )
|
| Edit: To be clear: the quote is referring to a negative DST
| start, rather than a negative DST offset.
| hnbad wrote:
| I think you misread that. America/Nuuk doesn't have reverse DST
| (which is easily solved by just switching DST and non-DST
| around). It _starts_ DST at a negative offset because the
| offset is defined as relative to the previous day.
| LysPJ wrote:
| Yes, this is indeed a different situation and my comment
| doesn't make that clear. Thank for pointing that out. I've
| made an edit.
| extraduder_ire wrote:
| In the github repo the article links, there is a large number
| of comments about the Europe/Dublin time zone in the europe
| file, including one quote from Ulysses:
| https://github.com/eggert/tz/blob/7748036bace8562b9c047f368c...
| bjoli wrote:
| A friend of mine has been visiting places with weird time related
| things going on, because it is interesting and takes you funny
| places.
|
| He has been to Lord Howe. Now I know why. He has a user account
| on HN. I will ask him if he wants to make an appearance here...
| dv35z wrote:
| Please do! Announce his arrival using his favorite time zone,
| and see if we can figure it out...
| uludag wrote:
| > Wrote a script in emacs lisp to calculate Ramadan
|
| I found this pretty funny, but a spot on solution. The
| solar/calendar features of Emacs are surprisingly robust and easy
| to work with.
| imrejonk wrote:
| I find it slightly ironic that a blog that's educating (and
| entertaining) us on time and timezones does not itself mention
| when its blogposts were published, at least on mobile.
|
| This one appears to have been published in the summer of 2024.
| rozenmd wrote:
| Seems like pretty timeless content to me.
| tuoret wrote:
| There's a couple of things that made me think the article was
| way older than it actually is (and made me mildly irritated
| that it doesn't include the publication date).
|
| First off, the author starts off by talking about GMT and
| goes on to educate the reader how UTC is actually the current
| standard. Maybe it's just me but I thought this would be
| common knowledge by now, while the author frames this as some
| sort of a revelation.
|
| Then there's the jab about The IERS breaking Wikipedia's css
| which just doesn't seem to happen on the two devices I opened
| it on, so I assumed that was the case prior to Wikipedia's
| redesign.
|
| Minor things for sure, and the content itself is pretty
| timeless (heh).
| SAI_Peregrinus wrote:
| Leap seconds are also set to be removed eventually. UTC
| will become UT1 with a fixed offset, at least until enough
| seconds add up for the BIPM to care about the offset and
| insert a leap minute or hour or something TBD.
| zokier wrote:
| > UTC will become UT1 with a fixed offset
|
| I'm not sure what you mean, but this sounds wrong. The
| whole thing about leap second abolishment is to
| effectively disconnect UTC from UT1, i.e. allow DUT1 to
| grow unbounded and make UTC a fixed offset of TAI.
| AStonesThrow wrote:
| While there's no explicit publication date, there are a few
| shell commands which strongly imply that the blogger was
| writing on or about "Tue Jul 30 23:52:11 UTC 2024".
| FateOfNations wrote:
| For a while (currently?) there was SEO "wisdom" going around
| about not putting dates on content so that search engines would
| treat the content as "evergreen" rather than "stale".
| ajdlinux wrote:
| > This one appears to have been published in the summer of
| 2024.
|
| "Summer" in certain parts of the world, at least.
| imrejonk wrote:
| Sharp!
| Gormo wrote:
| I figured I'd check the RSS feed to see the timestamp there,
| only to discover that this "blog" doesn't even have a feed!
| ucarion wrote:
| Thanks! The irony is not missed on me. I think I have the dates
| internally in the article metadata, just didn't set up my Hugo
| templates to display it. TODO!
| imrejonk wrote:
| Ah, so it wasn't some SEO trick (see your sibling comment)
| after all :)
|
| Thanks for the fun and informative blog post!
| alexjplant wrote:
| Earlier this year I had to write a function to find the current
| local time given a US address. The naive way to do so would be
| via a static mapping of state to time zone but there are a few
| edge cases that preclude doing this; in the interest of cost and
| speed relative to this specific application I spent a few dollars
| on a CSV that maps every US ZIP code to UTC offset and whether
| DST is followed (among other data). pytz takes IANA timezone
| names so I ended up having to map offset and DST info manually to
| specific timezones. As it turns out the US has a fair number of
| weird edge cases for overseas territories and military bases that
| necessitated the use of things like "Etc" zones [1] that have
| funky semantics (because of Unix for some reason if Wikipedia is
| to be believed).
|
| [1] https://en.wikipedia.org/wiki/Tz_database#Area
| koliber wrote:
| A good approach would be to map a zip code to the named
| timezone (e.g. US/Eastern). Then, if you need to produce the
| UTC offset, apply the timezone to a date using pytz and get the
| offset.
|
| The named timezone is special as it is constant. The UTC offset
| timezone (e.g. "-05:00") and the shorthand name (e.g. "EST") is
| NOT constant over time for a given location, because of
| daylight savings time. "US/Eastern" flips between "-05:00" and
| "-05:00", as well as between "EDT" and "EST".
|
| If you ask someone what their timezone is and offer them
| offsets or the short names, it causes confusion for everyone.
| hocuspocus wrote:
| > The naive way to do so would be via a static mapping of state
| to time zone but there are a few edge cases that preclude doing
| this
|
| More than a few, state is really the wrong resolution here, US
| timezones follow counties and native reservations borders.
|
| ZIP codes should probably be good enough but I'd be careful
| too. If your volume of addresses isn't too crazy, the robust
| way is to reverse geocode them and use a library that gets you
| the IANA identifier from timezone shapes.
|
| https://github.com/RomanIakovlev/timeshape is maintained by a
| former coworker who could open source some of the work we did
| internally.
| apelapan wrote:
| There used to be at least one airport in a tribal area in the
| US, that had the timezone of the reservation (not same as
| state) but the DST of the surrounding state (not same as
| reservation).
|
| Can't remember the code for it now, had a lot of interesting
| timezone issues in a previous job.
| kstrauser wrote:
| IIRC you crossed 6 time borders in 30 miles if you flew the
| right straight line across it.
| foobarchu wrote:
| My favorite is the hopi reservation, which does not observe
| DST and exists entirely inside of the Navajo reservation,
| which does observe it, and which exists entirely within
| Arizona, which again does not observe DST, and exists
| entirely within the United States which does observe DST in
| the general case.
| ComputerGuru wrote:
| > state is really the wrong resolution here, US timezones
| follow counties
|
| County is the smallest resolution one can reasonably use, but
| in terms of what timezones themselves follow, that would be
| metro areas. I.E. the Chicago metro area has its timezone and
| cities (or counties, if you will) that are part of that metro
| region, even when belonging to other states that largely
| follow a different time zone, follow the metropolis' tz
| instead.
|
| (Not arguing with you but clarifying the meaning of "follow"
| here.)
| seoulbigchris wrote:
| As a young engineer right out of university back in 1985, one
| of my early tasks involved merging together a bunch of
| telemetry data provided on mag tapes recorded at different
| radar sites (in the USA). One or two of the systems time
| stamped their data in local time, and all the others used UTC.
| I remember buying one of those old Farmers' Almanacs in order
| to make an algorithm to account for DST. When I read the rules,
| I threw up my arms in despair.
|
| The almanac gave nominal rules for the transitions. But there
| was a footnote explaining that these transitions had and will
| continue to be adjusted year to year due to Congressional
| intervention. I showed this to my boss and said, "If I could
| write an algorithm that predicted future votes of Congress, I
| would be a billionaire and could quit this engineering job."
|
| I think in the end I coded the algorithm with the recent known
| transitions, and the nominal rules for future ones. What else
| could you do (this was before everyone was networked, and the
| code ran on standalone computers like a VAX).
|
| I also learned that task of merging three sources of tracking
| data, each with its own validity and measurement degradation
| status, was an absolute nightmare. But still easier than
| predicting future actions of Congress.
| TheNewsIsHere wrote:
| This is a fantastic story, well and amusingly told.
| gorkish wrote:
| I see you too have wrestled with GreatData's time zone data
| being hot garbage. Been that way for decades.
| __alexs wrote:
| I think the old Riyadh timezone is the weirdest personally
| https://github.com/eggert/tz/blob/be62d5918223b4df209cc94163...
| NelsonMinar wrote:
| agreed. From pytz's docs: "the intention was to set sunset to
| 0:00 local time, the start of the Islamic day. In the best case
| caused the DST offset to change daily and worst case caused the
| DST offset to change each instant depending on how you
| interpreted the ruling"
| ucarion wrote:
| If you go by the wtf-ness of the comments on a tz, Asia/Riyadh
| has gotta be up there. But contemporarily it behaves as
| `<+03>-3`, which is vanilla.
| bob1029 wrote:
| The Japanese calendar has always been the most fascinating
| date/time thing for me:
|
| https://devblogs.microsoft.com/dotnet/handling-a-new-era-in-...
| bradley13 wrote:
| Hard-coded yearly transitions for a particular region, because
| they just have to have their own, special rules? Transitioning to
| DST on Sunday at -01:00 (minus one o'clock)? Or at 24:00?
|
| Honestly, the IT world has a certain amount of influence. There
| comes a time where we could collectively just say "no". No, you
| are not that special, use any of the already incredibly flexible
| options that you have.
| magnio wrote:
| > There comes a time where we could collectively just say "no"
|
| Well, C23 mandates a byte is 8 bits, and POSIX 2024 disallows
| newlines in filename, so we do exercise that right times to
| times.
| growse wrote:
| I think you've got who's serving whom the wrong way round.
| szemy2 wrote:
| > With a "designator" time that doesn't mean much
|
| This might not 'mean much' to the computer, but it means a lot to
| the human. The computer uses it to communicate with the human and
| the humans between each other. When I arrange a meeting across
| timezones I will say CET 16.00 or ET3.00PM and they will
| understand it faster than saying how much offset we are from UCT.
| jamiehall wrote:
| > Btw it's called UTC (Universal Time Coordinated? huh?) because
| the same folks who publish UTC also publish UT1, which is UTC
| sans the leap seconds.
|
| I'm not sure that's right! According to legend among metrologists
| I've talked to, "UTC" was chosen as a compromise candidate: it
| makes sense as an acronym in neither English nor French.
| samatman wrote:
| So like ISO, then.
|
| Which is not an acronym, btw, it's just styled in all caps, and
| is to be pronounced "iso" rather than "eye-ess-oh".
| nokeya wrote:
| I always say that timezones and font rendering are the most
| sucking problems that developer can encounter. Both have a ton of
| weird quirks, both implemented differently across various target
| devices/OSes and require a lot of time and effort to implement
| reasonably right.
| ChrisMarshallNY wrote:
| I've found the best way to deal with TZ conversions, is to use
| UTC as a common fulcrum.
|
| I convert the target TZ to UTC, using my local utility, then use
| my local TZ utility to convert from UTC to local.
|
| But I write iOS software, so I have very solid local tools at
| hand. It might be more problematic, on, say, a webserver.
|
| On a related note, I wrote this utility[0], some time ago. It
| uses the TZ map from the TZ Boundary Builder project[1].
|
| [0] https://github.com/LittleGreenViper/LGV_TZ_Lookup
|
| [1] https://github.com/evansiroky/timezone-boundary-builder
| klysm wrote:
| UTC is generally a good idea for storing, but there are still
| some ways to have that bite you. If a user enters a local date
| time for a future event in a particular time zone, converting
| that to UTC could result in incorrect behavior if the timezone
| definition changes. It depends on if the user meant that UTC
| time or if they meant the local time.
| ChrisMarshallNY wrote:
| That's why I do it at the time the query is made. I don't
| ever store UTC.
| bmicraft wrote:
| > if the timezone definition changes
|
| Or if DST kicks in/out. No need to have the definitions
| change.
| klysm wrote:
| Depends on how naive the conversion is. If you consider DST
| while making the conversion that's not really a problem
| Ndymium wrote:
| It can also cause trouble if you store past events but do not
| store the user's local offset or timezone at the time of the
| event. If you aggregate these events later into a dataset of
| "events by hour", they may be grouped wrong (from a user's
| perspective) if you convert them all to the user's _current_
| timezone.
| ajanuary wrote:
| You need to be careful with some circumstances. I recently had
| to fix up a case where someone had tried this with a recurring
| local date. Something needed to happen at 4am local time every
| day. They had converted 4am local time to UTC based on the
| timezone offset on the day the config was saved. This then
| restored incorrectly when the timezone offset changed because
| e.g. a DST transition.
| ChrisMarshallNY wrote:
| Well, I guess I should have written in the OP, that I do both
| conversions _at the time of the query_. It 's useless to try
| storing the UTC. It needs to be JIT.
| tankenmate wrote:
| "Running cron jobs on an hourly basis doesn't in practice have
| very weird interactions with DST"
|
| Of course every sane person runs their default system clock on
| UTC and lets users pick their own local time. That way cron
| always does the "right thing"(TM).
| rubenv wrote:
| That's true if you need to clean up temporary files every night
| or make a backup.
|
| But what if your cronjob has an effect in the physical world,
| locally? E.g. open the parking gates every morning.
|
| The world is inherently messy :-)
| roryirvine wrote:
| That sort of thing would be best handled by your own user's
| crontab, so would naturally inherit that user's TZ.
|
| If you must run it as root, you can specify a CRON_TZ
| variable on a per-file basis, which will override the
| default.
| tankenmate wrote:
| Well assuming that the gates don't move timezones. But
| obviously jobs that need to run for a given timezone should
| be configured to run in that timezone.
| cube00 wrote:
| Unless the gates need to open at 2:30am and in the case of
| daylight savings time that hour is skipped.
| tankenmate wrote:
| Not if that cron file (you can have multiple cron files
| per user/system) is configured to run in the local
| timezone.
| sib wrote:
| But then wouldn't the job run twice when time "falls
| back"?
| tankenmate wrote:
| no, it would run either twice at the "same time" as it is
| read out, but obviously 60 minutes apart time duration
| wise; but this can't be helped as this time "existed"
| twice in that time zone. Or conversely in spring that
| time wouldn't happen at all, but the cron job will still
| run 60 minutes apart time duration wise. But this is the
| downside of local time, just make sure if you want to
| open a door at 01:30 local time that that is what you
| really want, because the unintended consequences could be
| a bit strange.
| cesarb wrote:
| > That's true if you need to clean up temporary files every
| night or make a backup.
|
| Making a backup is usually reserved for the quietest hours of
| the morning, so that it does not compete as much for
| resources with the normal operation of the system; in my
| experience, the quietest hour is usually around 4:00 local
| time.
| sgarland wrote:
| Tangentially, Debian's vixie-cron did / does handle DST, but it
| did not handle TZ changes [0], as I discovered.
|
| [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019716
| vander_elst wrote:
| I still hope that someday the whole world will run on UTC0 and
| there is no more time zones madness. I know the day will likely
| never come but I like to keep dreaming.
| sethammons wrote:
| Some dates will change when at relatively strange times. For
| some, the date change will be two hours into the workday. That
| seems odd. And you lose some info too: if I want a 07:30 (am)
| meeting, is that during the working hours of my target
| location? With offsets, I can see that it is 12:30pm at my
| target location and know that I am scheduling over lunch very
| likely. With no timezones, how do I know what time of day it is
| there? Recall some anchor time and do mental math each time?
| "Morning in London is 13:00, so four hours later right before
| lunch is 17:00, and for an LA meeting, let's see, morning there
| is 05:00, so 17:00 is evening time, I think
| vander_elst wrote:
| > the date change will be two hours into the workday. That
| seems odd
|
| Seconds minutes and hours can change but the day cannot?
|
| > mental math each time
|
| Usually meetings are setup using an app and shared calendars
| should actually help here, a person can have meeting slots
| and out of office time, that should provide the same info.
| logistically I don't see that much of a difference from the
| current situation
| iggldiggl wrote:
| > Seconds minutes and hours can change but the day cannot?
|
| The calendar day being aligned to the sleep/wake cycle and
| changing when most of the population is either asleep or at
| least might not terribly care about the actual date does
| help quite a bit.
|
| > Usually meetings are setup using an app and shared
| calendars should actually help here, a person can have
| meeting slots and out of office time, that should provide
| the same info. logistically I don't see that much of a
| difference from the current situation
|
| It'd also wreck any time references in any kinds of stories
| that aren't consumed locally. So every time I
| read/watch/listen to a story that isn't set where I live,
| I'd first have to look up the local time to make sense of
| any time references.
| hypeatei wrote:
| I'd rather timezones be split based on actual logic rather than
| politics and eliminate things like daylight savings. It's
| insane to me that China has one timezone because they felt like
| it. People must sleep terribly in certain regions.
| marcthe12 wrote:
| Yep. And the logic can be made very easy. Outside polar
| regions or outer space, timezone could simply be the
| longitude/15 degrees rounded to a constant fraction. This is
| not perfect as cities maybe in 2 time zones but this
| basically a really good approximation.
| stevage wrote:
| This is awesome - I have always kind of wondered how this stuff
| was implemented, but never looked it up.
| azernik wrote:
| The "Asia/Jerusalem" weirdness is because Daylight Savings Time
| is a big church-and-state issue. Religious people want the
| workday to be convenient for holidays that start at sunset.
|
| This led to decades (up to the mid-'00s) where Daylight Savings
| was the result of annual negotiations between religious and
| secular parties. It often caused problems when the decision
| wasn't made until juuuust before the transition date.
|
| There are still exceptions built in to prevent Daylight Savings
| from ending on Rosh HaShanah, so that's probably the future
| stuff.
| rob74 wrote:
| Reading this, and considering the limited advantages of DST
| (especially for a country that is relatively far to the south),
| I wonder why they didn't decide to scrap DST completely? Maybe
| they will if the EU eventually manages to do it?
| lazide wrote:
| If they didn't have that to argue about, what else would they
| do with their spare time?
| maratc wrote:
| I would argue that DST actually makes most sense in 30-40
| degrees of latitude.
|
| With about 13 hours of sunlight in the summer, split evenly
| around the mid-day, it comes down to 05h30 to 18h30 under
| light. There are many more people who would be out there to
| enjoy the sunlight between 18h30 and 19h30 than there are
| between 05h30 and 06h30.
| bena wrote:
| I really dislike this argument of "I'd rather enjoy the sun
| in the evening than in the morning" ignoring all of the
| other problems it causes.
|
| Sunlight in the morning is _useful_. It 's better for your
| sleep rhythms. It's safer for school children, etc.
|
| And to be completely fair, I don't see that many more
| people "enjoying the sunlight" during the weekend when they
| have the entire day to do so. Like, what is the sun going
| down at 6 _really_ preventing you from doing that you
| couldn 't do otherwise?
| maratc wrote:
| > I really dislike this argument of "I'd rather enjoy the
| sun in the evening than in the morning"
|
| My argument is not "I'd rather enjoy the sun in the
| evening than in the morning", my argument is "From what I
| can observe, most people would prefer an hour of sunlight
| at the end of the day rather than in its beginning". This
| is not about what _I_ think, it 's about what _most
| people_ think. > what is the sun going
| down at 6 really preventing you from doing
|
| Again, my observation is that _most people_ , given a
| choice of A. having sunlight between 5am and 6am; or B.
| having sunlight between 6pm and 7pm, would prefer option
| B, simply for the reason that more are awake during that
| time.
| bena wrote:
| Did you take a poll, or do you just have the feeling that
| that is the case? Not to mention, it's a bit weaselly. It
| offsets the burden of defending the position to "most
| people".
|
| And it doesn't even matter what "most people" think.
| "Most people" in this case, would be wrong. Even if it
| were "most people" and not "most people whose opinions
| you've happened to remember on the subject because they
| happen to align with yours".
|
| And it's going to get darker earlier in winter. That's
| just what it does. People are really just lamenting the
| lack of daylight hours in general. Because during the
| winter, few places have sunlight during 6pm and 7pm even
| if we kept DST year round. What they say they want is
| sunlight between 5pm and 6pm. And after the clocks roll
| back, it'll start getting dark soon after 5.
|
| And once again, I ask, for what? Having the sun rise just
| after 6am is better for everyone. School kids waiting for
| the bus are safer, kids walking to school way safer.
| Better driving when you're waking up. Everything is more
| in line with your circadian rhythms, etc.
| samatman wrote:
| > _It offsets the burden of defending the position to
| "most people"._
|
| Decisions where the only effect is to align something
| arbitrary with people's preferences can only be made
| through appeal to the majority.
|
| > _And it doesn 't even matter what "most people" think._
|
| Yes. Yes it does.
| maratc wrote:
| > And it's going to get darker earlier in winter.
|
| It's summer we're talking about when we talk about DST.
| There's no DST in the winter. > School
| kids waiting for the bus are safer, kids walking to
| school way safer.
|
| For several months in the summer, the schools are closed.
| Other months during DST, the schools start at 08h00 and
| the vast majority of the kids wake up about seven-ish, to
| leave their house at about 07h30. It is inconsequential
| for the kids whether the sun has risen at 06h30 or at
| 05h30 that day; when they wake up, there's light outside
| anyway.
|
| For the rest, let me give you an analogy. For several
| months this coming summer, I am going to give out an hour
| of free internet[0] each day. This won't interfere with
| the (paid) one that people are having otherwise. I'm not
| going to ask the question "would _you_ prefer this hour
| to be between 05h30 and 06h30, or between 18h30 and
| 19h30? " but I am going to ask this question instead:
| What would the majority prefer, in your opinion?
|
| [0] - any useful utility can be substituted: free hour of
| water, free hour of electricity, etc.
| alwayslikethis wrote:
| Yeah. DST really boils down to tricking people to wake up
| earlier. But you can get all that sunshine by waking up
| earlier yourself at 5am. No need to force an awkward
| schedule change on everyone.
| layer8 wrote:
| The EU likely won't scrap it, because the CET countries want
| to stay in a common time zone (no new time zone borders) for
| economic reasons, but either the very Eastern or very Western
| ones in that range would object to permanent DST or permanent
| non-DST, because it would move them too far from the solar
| day either in winter or summer. It can't be fixed without one
| country or another getting the short stick, which means it
| won't be fixed.
| yyyfb wrote:
| If the continental US can do it (and it looks like it might
| soon, with California voting for it) I'm not sure I buy
| that argument. Heck if China can survive on one timezone...
| layer8 wrote:
| They certainly could if they had started that way, but
| changing it now will disadvantage at least one of the
| countries (Spain for example), and those countries'
| politicians don't want to risk the ire of their voters
| for the greater good. And DST is regulated on the EU
| level, so can't be changed by individual EU members
| without breaking EU law, like apparently individual US
| states can.
|
| It's status quo bias and loss aversion. Similar to how it
| would be better for the US to change their voting system,
| but it will never happen because it would disfavor one of
| the political parties who'd have to approve the change.
| ascorbic wrote:
| Spain should take the opportunity to move to WET like
| Portugal
| layer8 wrote:
| They have more economic relations with the rest of the
| CET countries combined, so it's more beneficial to stay
| in the same time zone.
| Navarr wrote:
| US is the same way; my hot take has always been "time to
| move to a -/+ 30 minute timezone"
| RegnisGnaw wrote:
| There is no more exceptions, IDT got extended to last Sunday of
| October in 2013.
| azernik wrote:
| Huzzah, at last!
| ars wrote:
| According to Wikipedia: "If the end of IDT falls on Rosh
| Hashana, then IDT will end on the first Monday after October
| 1."
| ars wrote:
| It's because of Passover: The Seder (main celebratory meal)
| lasts till midnight and later, and it's a very big deal for
| children.
|
| So they don't want Daylight Savings Time to make it end even
| later than it already does.
|
| It's also because of the fast day of Yom Kippur - people wanted
| the faster to end 1 hour earlier.
|
| So they wanted DST to match up to those days - but that made
| the DST period too short, and led to the negotiations.
| entuno wrote:
| The time zone in Palestine is a bit weird as well:
|
| https://en.wikipedia.org/wiki/Time_in_the_State_of_Palestine
|
| They have DST, but it's not on fixed dates, the government just
| announces each year when it's going to start and end. Sometimes
| with less that a week's notice, which must cause all kinds of
| interesting problems for people.
| yokoprime wrote:
| Without getting deep into politics I don't understand why they
| would prioritize spending effort on DST at all, seems like
| there are plenty of other concerns.
| DoughnutHole wrote:
| If your life is dominated by an us vs them dynamic small
| demonstrations of difference become hugely important.
|
| In a similar vein different people in Xinjiang in China
| observe entirely different timezones - Han Chinese observe
| Beijing time (because China is insane and uses one timezone
| despite spanning 5), while Uyghurs observe a local time 2
| hours behind.
|
| It's a small show of resistance, which is sometimes all a
| people have if they have limited control of their own
| affairs.
| jdietrich wrote:
| Again, without wanting to get too political, I think it's
| essentially bikeshedding. The Palestinian National Authority
| is riven with factional conflicts and has very limited state
| capacity. That almost inevitably leads to a lot of bickering
| over largely irrelevant decisions as a symbolic but hollow
| demonstration of political authority. The ability to make the
| decision takes on an importance completely out of proportion
| with the actual significance of the decision.
| grotorea wrote:
| I don't see why announcing DST would be a big effort. And it
| saves on electricity costs.
| macspoofing wrote:
| Announcing is not a big effort. Having millions of people,
| and thousands of companies (in the territory and outside
| the territory) adjusting to the announcement is a big
| effort. If you're going to have DST, you want it to be
| stable and predictable so that people can plan for it.
| Kwpolska wrote:
| Even if DST did save something (it does not), it becomes a
| problem when your timekeeping is done by computers. My
| computers know I live in Poland (Europe/Warsaw), and they
| know the DST rules. I can trust the time on my computers'
| clock matches the official time the government recognizes.
|
| In Palestine, this depends on my OS vendor managing to
| update the tz database in the short window before the
| official announcement and the decision coming into force.
| (I believe the tz database makes some assumptions based on
| past performance, but the government can change their mind
| any year.) If my OS does not update, I need to change my
| time zone manually to something that has the right UTC
| offset, and then I need to manually change back in the
| autumn, and I can never be 100% sure if any given computer
| shows the official time.
| FateOfNations wrote:
| Most of the population there is interested in those dates for
| non-DST-related reasons. They will want to know when Ramadan
| begins and ends, regardless of whether it's used to determine
| DST.
| ComputerGuru wrote:
| You (and everyone else opining here) are missing the
| practical context: DST makes Ramadan easier, because the sun
| sets an hour earlier. Yes, you are fasting the same number of
| hours, but your day "starts" at a point fixed to the TZ-
| adjusted clock and the sooner sunset arrives, the shorter
| your effective day.
| weinzierl wrote:
| Not sure if true today, but used to be the case in Brazil too.
| Once almost missed a flight because of that.
| marcosdumay wrote:
| Brazil doesn't have DST anymore. And when it had, it used to
| be announced with 6 months of antecedence. It also had
| "standard" dates that were almost always used.
|
| If your comment was about the 2019 change that almost all
| computers got wrong, this one was announced with 6 months of
| antecedence like most others.
| arrowsmith wrote:
| This is mentioned in the article.
| karel-3d wrote:
| It's in the actual article. It's tied to Ramadan.
| xd1936 wrote:
| Which leads to an interesting phenomenon where two people
| living in the same physical place might observe two different
| current times depending on how they identify ethnically and
| geopolitically. Israeli and Palestinian daylight savings times
| don't necessarily begin or end on the same day.
| dfc wrote:
| Does anyone understand what was meant by _" This is because
| almost every standard (except ISO8601, whatever) is just a file,
| and you can read it."_ Initially I thought it was because the PDF
| of ISO-8601 is not a file commonly distributed with operating
| system. But that's not unique to ISO8601, you won't find IEEE
| 1588-2019 or NMEA 0183 v4.11 on your computer either. For ~20$ I
| think I can buy a PDF of the standard from ISO. Is there
| something special about ISO8601 that is not contained in the
| standard?
| NeoTar wrote:
| Possibly joking about the .iso file-type for optical disc
| images?
|
| Or maybe that 'most' ISO standards that are encountered by
| engineers are defining file-types.
|
| I'm also a big fan of ISO-3166 though !
| sundarurfriend wrote:
| I believe the IEEE and others also would come under the
| exceptions to the "almost" - anything you'd have to make a
| special effort to seek out and purchase.
|
| > Don't let people bully you into thinking that just because
| something is complicated, it's impossible. > This is because
| almost every standard (except ISO8601, whatever) is just a
| file, and you can read it.
|
| In context, (my interpretation is that) "standard" includes
| things like The Time Zone Information Format [1], the GNU docs
| about TZ [2], etc. I think the idea is to say "the documents
| laying out the details of complicated things are still just
| documents, you can read them if you're interested and don't
| have to just see them as meant of domain experts. Some of them
| have barriers to access like the ISO documents, but even
| excepting those you have direct access to most everything you
| might want to understand, don't let the idea of _standards_
| intimidate you. "
|
| [1] https://www.rfc-editor.org/rfc/rfc8536.html [2]
| https://www.gnu.org/software/libc/manual/html_node/TZ-Variab...
| lozf wrote:
| > For ~20$ I think I can buy a PDF of the standard from ISO.
|
| You might find most standards for ~20 USD, but ISO8601 direct
| from iso.org will set you back 173 CHF (~200 USD) for part 11,
| 194 CHF (~220 USD) for part 22. For $20 you get only the latest
| amendments from them.
|
| Meanwhile the Estonians will gladly sell you their version of
| part 1 for just under 30 USD.3
|
| 1: https://www.iso.org/standard/70907.html
|
| 2: https://www.iso.org/standard/70908.html
|
| 3: https://www.evs.ee/en/evs-iso-8601-1-2019
| dfc wrote:
| Thank you. I was a little surprised by the price but I guess
| I naively hoped it was a change of heart from big standards.
| aleksi wrote:
| The most interesting timezone I ever encountered is Europe/Moscow
| on and around January 1, 1900. If you decide to use that date as
| a zero date in your code (for example, to handle the transition
| from two digits per year), you will be in a lot of pain: the
| offset was +02:30:17. Yes, with 17 seconds! Demo:
| https://go.dev/play/p/lq36Plr1sIL
| iso8859-1 wrote:
| The tzdb assumes Local Mean Time (LMT) was used all over. For
| example, the tzdb has Africa/Monrovia still using LMT in 1970.
|
| https://en.wikipedia.org/wiki/Local_mean_time
| Kwpolska wrote:
| > Yeah, this stuff is weird, but only finitely so, because
| ultimately a computer's gotta implement them
|
| Historic data can be recorded. Rules like "last Sunday in
| October" or "first day of Ramadan" can be implemented and handled
| automatically (even if the current Unix implementations don't do
| non-Gregorian calendars out-of-the-box). But there can be time
| zones whose DST rules are "if the groundhog sees its shadow, we
| start DST two weeks later, otherwise, there is no DST this year".
| Some countries actually implement this, except the groundhog is
| replaced by your friendly local regime.
| bdmatatu wrote:
| > It's not like programming languages support representing
| 61-second minutes anyway
|
| Raku supports leap seconds. see
| https://docs.raku.org/type/Instant
| gausswho wrote:
| Excellent read around the acrobatics of timezone software. It
| really is quite flexible.
|
| It leads me to wonder. If it's all just an automated and finite
| offset, there's no reason for daylight savings policies to hew to
| 60 minutes adjustments.
|
| Couldn't a nation decide to have a continuously changing offset
| throughout the year? It might make their offset lookup table
| substantially longer, but this could 'solve' daylight savings
| time It'd be adjusting all the time and you wouldn't notice, just
| you don't notice when leap seconds occur.
|
| Those who rely on analog clocks might no longer adjust the same
| direction each time!
| lazide wrote:
| Please don't give them any ideas.
| fragmede wrote:
| India is UYC+5:30, and doesn't do daylights savings time, which
| is interesting for interacting with the rest of the world. Of
| course, China famously has one time zone despite being really
| wide which makes things interesting both internally and
| externally.
| em500 wrote:
| Most of the world doesn't do DST either[1], nowadays it's
| mostly a European/American thing.
|
| [1] See the map at https://en.wikipedia.org/wiki/Daylight_sav
| ing_time_by_countr...
| Gormo wrote:
| The logical conclusion of going down that route would be to
| dispense with the concept of time zones altogether, and just
| revert to using local solar time.
| crazygringo wrote:
| Which would make scheduling Zoom meetings or even just phone
| calls hell.
|
| Especially when everyone's half-hour blocks are misaligned
| with each other's so you can't even stack meetings
| efficiently.
| iggldiggl wrote:
| And public transport timetables, which were the original
| reason timezones were introduced in the first place.
| mywittyname wrote:
| This is why I think we should entirely ditch the concept
| of timezones. Clock time, as we use it, is largely
| decoupled from solar time anyway, and all attempts to
| reconcile the two just lead to confusion.
|
| We already have terms a few terms to tie events to solar
| time, for example, a park being open from dawn to dusk.
| And without time zones, we might come up with a few more.
| PopAlongKid wrote:
| > If it's all just an automated and finite offset, there's no
| reason for daylight savings policies to hew to 60 minutes
| adjustments.
|
| For as long as clock sync for electronic devices has been
| common, I have suggested to anyone who would listen that we
| should adjust forward 10 minutes on the first Sunday of each
| month for six months, and then back 10 minutes on the first
| Sunday of the other six months. A ten minute change once a
| month is not only easier to adjust to (almost unoticeable), but
| if you miss it, it's not as big a deal as being off by an hour
| would be.
| Buttons840 wrote:
| Moving up and down at a linear rate would result in a saw-
| tooth-like wave, but the length of days change in a sine
| wave. Why not have the clocks sync themselves to sunrise time
| based on their timezone and latitude? I don't think this
| would be much different, in practice, than changing times at
| a linear rate.
| mywittyname wrote:
| This would lead to a monumental amount of confusion.
|
| The primary time keeping device in my house is the clock on
| my stove; I wear old school watches a lot; and most of my
| cars are old and have old clocks in them. I can't be the
| only one, so multiply this by at least a few million other
| people in America alone.
|
| Sure, you can tell everyone they need to ditch dumb clocks
| and replace them with internet-enabled smart clocks. But I
| think that's a far more onerous undertaking than just
| dealing with the fact that solar time and clock time are
| mismatched.
| jerska wrote:
| Adding to my sibling comment, time is also mostly used as a
| coordination system. Being offset by a few minutes would
| make aligning meetings with your remote coworker an even
| bigger nightmare than it is now.
| nialv7 wrote:
| Why don't we take it to the extreme then? Just make the time
| the Sun rises 6am always. And make seconds longer or shorter
| to adjust.
| VyseofArcadia wrote:
| > but this could 'solve' daylight savings time
|
| This ignores the easiest solution to daylight savings time.
|
| _Stop doing daylight savings time._
|
| My preferred solution would be permanent standard time rather
| than permanent DST, but I'll take what I can get as long as we
| stop changing the clocks twice a year.
| akira2501 wrote:
| > It really is quite flexible.
|
| Other than considering current legally defined timezones as
| "legacy" definitions and then removing them for no reason other
| than to follow European fashion.
|
| So, flexible, but managed by inflexible university types.
| ucarion wrote:
| In theory, this can be expressed in tzdb. Obviously, it will
| cause problems.
|
| The only really important assumption not obviously present in
| TZif's data format is that when you go from a local time to a
| UTC time, there can only be up to two possibilities. A lot of
| software works on that assumption, for instance
| java.time.LocalDateTime has a withLaterOffsetAtOverlap():
|
| https://docs.oracle.com/javase/8/docs/api/?java/time/LocalDa...
|
| That implicitly assumes that whenever it's ambiguous what
| 2:30AM means, you can only have two possible solutions (pre-
| and post-DST). If a timezone were ever to manipulate its
| offsets so that there were three or more solutions (such as if
| they did a "fall back" at 2:00AM and then 2:15AM or something),
| a lot of stuff would be unable to represent that.
| ochrist wrote:
| The article says that "Nuuk is in Greenland, and is part of the
| greater EU cinematic universe."
|
| It is correct that Greenland is part of Denmark, and Denmark is a
| member of EU. But Greenland voted several years ago to stay out
| of the EU.
| dmd wrote:
| Which is why it's part of the _greater_ universe, not the
| regular one.
| armada651 wrote:
| Greenland is one of those spin-off movies that is part of the
| cinematic universe, but is generally considered to be non-
| canon.
| IggleSniggle wrote:
| Like how Spider-Man actually belongs to Sony, not Marvel, and
| it gets loaned back to Marvel? Or more like how Blade isn't
| part of the MCU, but totally belongs to Marvel?
| ta1243 wrote:
| Except Blade _is_ part of the MCu now since Deadpool 3
|
| But I think the analogy may be being stretched
| IggleSniggle wrote:
| Ahh, figures. As soon as I said it I thought it likely
| that Marvel had roped it in at some point.
|
| Nothing is safe! Just wait til we get Star-Lord
| (Guardians of the Galaxy) accidentally facing off against
| some Jedi just so a writer can make some "Hans shot
| first" "inside" joke in some "way overshot the time
| travel to long ago in a galaxy far far away"
| plot...basically a movie to set up the joke in a trailer.
| ta1243 wrote:
| I'm just so relieved that Disney didn't buy Star Trek.
| Was slightly concerned by an offhand remark from the
| Doctor in the most recent Doctor Who series who made an
| off-hand comment about dropping in on the Star Trek
| people.
| toast0 wrote:
| Spider-Man belongs to Marvel, but is on conditional
| perpetual loan to Sony, who can optionaly loan it back to
| Marvel/Disney.
|
| Sony has to release a Spider-Man movie every N months, or
| they lose the license, and will probably never get it
| again, since Marvel started making their own films and now
| they're part of Disney. This is why Sony keeps making
| reboot trilogies. Better to shovel something out than to
| lose the license forever. It does make a nice backstory for
| the Spider-Verse though.
| ochrist wrote:
| In that case Greenland is accompanied by their 'sister
| country' The Faroe Islands, that has a similar status wrt.
| Denmark and EU.
| crazygringo wrote:
| Also, geographically it belongs to North America. Not Europe.
| lazide wrote:
| So.... Antman?
| kergonath wrote:
| > It is correct that Greenland is part of Denmark, and Denmark
| is a member of EU. But Greenland voted several years ago to
| stay out of the EU.
|
| Greenland is still part of the EU's overseas countries and
| territories. It's not like it's in a different universe.
| layer8 wrote:
| EU stands for Extended Universe here, probably. ;)
|
| https://en.wikipedia.org/wiki/Extended_universe
| IgorPartola wrote:
| I know this is a popular sentiment here but it bears repeating:
| timezones need to go away.
|
| Time according to timezones measures the position of the sun.
| Except when we clearly decide with daylight savings time that we
| don't care about the position of the sun, we just want it to be a
| certain time.
|
| When the sun is directly over NYC it is usually 1pm or 2pm,
| depending on time of year, but 5pm or 6pm in London. Why? Are
| these events happening at different times? No, they are happening
| at the same time. Why do we use a different number for them?
|
| Your "time zone" may decide that generally the workday is from
| 14:00 to 22:00. Why not? We already have second and third shift
| workers, so the idea of 9-5 is dead anyways.
|
| When I schedule a meeting with someone in Tokyo and I am in NYC,
| is the meeting not happening at the same time? Wouldn't it be
| easier to say "let's do it at 13:00"? We still would need to
| figure out if people are awake and at work but we have to do that
| now while also figuring out daylight savings, so not only time
| but day of the year matters.
|
| Heaven forbid you schedule a meeting or an event or a delivery or
| a stock trade and your time zone gets helpfully updated after you
| schedule the thing but before it happens. Better hope all the
| processes and software get that right or else!
|
| And here is my favorite example I recently encountered: what is
| the speed of federal laws in the US? Say the tax brackets are
| rewritten for 2025, starting "January 1". Cool, so if you work
| the NYE shift from 8pm to 4am in Chicago, is it the DC timezone
| that matters for your taxes? The local? If cannabis is legalized
| starting at midnight but you get arrested for possession at 11pm
| the day before in LA are you wrongfully detained or did you miss
| it by one hour?
|
| Timezones are 19th century thinking. We can do better.
| coldpie wrote:
| Nah. Any solution you come up with that accounts for how humans
| actually use time will just reinvent time zones. Could they be
| more cleanly specified than they are? Sure. But that's just an
| artifact of grandfathering in historical practices.
| IgorPartola wrote:
| See my reply to a parallel comment.
| Tor3 wrote:
| The point is really that as long as we don't live on
| Discworld we _have_ to divide the world into time zones.
| Either using different local time zones, or using local
| awake /sleep zones. Either way you have time zones.
| aniforprez wrote:
| Unless you can propose a proper way to locally represent time
| where a person is currently present in relation to the position
| of the sun then no, time zones will never go away. I know time
| zones suck for us as programmers but it's a practical way to
| separate different regions that will experience different times
| of day differently. As long as we have clocks and times with
| "midnight"s and "noon"s, time zones will exist. I assume once
| we truly become an interplanetary species and colonise multiple
| planets, we will begin to use different methods of time since
| 24 hour/365 day clocks are going to be an Earth only thing but
| that's for future scientists to decide. There were proposals
| for daylight savings to go away but that seems to have
| disappeared into the ether for some reason.
| IgorPartola wrote:
| Just because you personally are used to a specific type of
| clock doesn't mean you can't imagine a different kind.
| Submarines use 24 hour clocks and give no hecks about where
| the sun is.
|
| The solution is to just use UTC. That's it. That means in NYC
| you'd get to work at 13:00 and go home at 21:00, which used
| to be 9am-5pm. That's it. Your whole transition has been
| completed. The rest is just what your calendar says. Niece's
| recital on Thursday at 19:00, beers with Greg at 23:00 on
| Friday, etc. It really isn't hard to imagine.
| hugh-avherald wrote:
| Why don't people just do this then? There's no overwhelming
| obligation on individuals to use the local timezone.
|
| I also think that your using the example of submarines --
| notoriously an onerous lifestyle that very few are capable
| of living -- pretty much torpedoes your implicit suggestion
| that this would not be too much of a change.
| rswail wrote:
| > pretty much _torpedoes_ your implicit suggestion that
| this would not be too much of a change.
|
| You did that on porpoise I hope.
| IgorPartola wrote:
| The reason it is hard being on a submarine isn't because
| of the clock. That's like saying that it is hard to be a
| construction worker because the hard hats aren't
| fashionable.
|
| And the reason why people don't just do that is because
| it is a network effect problem. We all need to buy into
| it. Like the metric system or driving on the same side of
| the road.
|
| And people do this. Haven't you seen people who routinely
| talk to people outside their timezones sign their email
| with their location and/or UTC work hours?
| coldpie wrote:
| > The solution is to just use UTC. That's it.
|
| Okay. I work in Minneapolis and need to schedule a meeting
| with someone in London. How do I know what UTC time is
| during daylight hours for both participants? Well, we can
| use a formula that will tell us where the sun in the sky
| for a given longitude. But that's kind of a chore. So let's
| break ranges of longitude into zones and create a lookup
| table. Hang on a minute...
|
| I've just traveled to Tokyo from Minneapolis. What time do
| I need to set my alarm to, to wake up an hour before most
| businesses open? Well, I can use trigonometry to figure out
| what UTC time the sun will rise at this location on Earth.
| But that's kind of a chore, so presumably each city will
| have an offset from UTC time that they all agree on to
| begin business hours. Hang on a minute...
| vundercind wrote:
| Traveling would be so much more disorienting. Forgetting
| what the local daytime range is and checking the position
| of the sun to guess whether you're closer to the front or
| back half of the day. Having to consult a table to figure
| out exactly _how much_ you 're going to inconvenience the
| person giving you a ride from the airport. Accidentally
| running into rush hour because you forgot that 1100 is 5:00
| here. LOL.
| IgorPartola wrote:
| So like when you fly from London to NYC and have no idea
| how long the flight actually is because it leaves at 10am
| and arrives at 9am? Timezones explicitly make travel
| harder, not easier.
| teo_zero wrote:
| > NYC you'd get to work at 13:00 and go home at 21:00
|
| And if you plan to meet your colleagues after dinner, would
| you say "see you tomorrow?".
| ta1243 wrote:
| OK, you're in LA. You finish work at 2300 on Monday.
|
| You have plans to go to the theatre on Tuesday after work.
|
| Is that 0100 on Tuesday (after finishing at 2300 on Monday)
| or 0100 on Wednesday (after finishing at 2300 on Tuesday)
| iggldiggl wrote:
| Along the same vein... how are public holidays supposed
| to be handled? Do those always start and finish at
| midnight UTC, even if midnight UTC happens to be right
| during the middle of the solar day (and everybody's
| waking hours)? Or does every place define a specific time
| (aligned to solar midnight or some other suitable point
| during the night) for when holidays are supposed to start
| and end, which is basically reintroducing timezones
| through the back door?
| Tor3 wrote:
| >That means in NYC you'd get to work at 13:00 and go home
| at 21:00,
|
| Fine.. so I'm going to have a teleconference with a company
| in NYC. Due to what you wrote above I now have an idea of
| what UTC time window to plan for - after all, I want to be
| able to reach them during their working hours.
|
| Then on Friday I have to schedule a teleconf with a company
| in Japan. When do they work, relative to UTC? You forgot to
| add that, so I have to find it somewhere.
|
| Hm, wouldn't it be nice if my computer could keep track of
| the working hours everywhere in the world. Let's make a
| database of that.. There's just one issue: How is this any
| better than using the timezone system we already have?
| Using that, I can figure out the local time in those
| places, and I can safely assume that they'll at least be
| working from around 09:00 local time. Having to instead
| keep track of their working hours relative to UTC doesn't
| seem like much of an improvement to me.
| IgorPartola wrote:
| You got it exactly right up to the last sentence. Yes it
| is exactly the same amount of work to figure out how to
| make a long distance phone call or schedule a meeting.
|
| Except for most people it is almost never a problem
| because most people aren't scheduling phone calls or
| meetings with unfamiliar locations.
|
| The benefit is obvious: things that happen at the same
| time have the same number associated with them. Just like
| we currently coordinate dates using a shared calendar, we
| coordinate times. And that has a local benefit as well.
| Aside from no more daylight savings time which we can
| achieve using other means, we also know when world events
| happen as they are being reported, we know when certain
| things take effect for countries that span multiple
| timezones now, we know the exact difference between any
| two given time points without asking "but where are they
| happening?"
|
| Again, imagine that we had unified time and some country
| somewhere said "hey we are using the same format but
| doing our own variable offset from it". That would be
| absolutely asinine. We are used to timezones and think
| they benefit us because of that familiarity. In reality
| we have had variable time even in the same timezones
| before and it was universally a bad idea that was shut
| down soon as people started traveling.
|
| Oh and consider that due to cultural differences your
| example of scheduling meetings is already flawed: do you
| know if Tokyo wraps up the workday at 4pm or 6pm? Is
| there an hour or two hour lunch break in Barcelona? When
| do people actually come to work in Rome? Are banks open
| on Saturdays in Baghdad? Timezones do not solve these
| issues whatsoever so you still need to do the lookup of
| "when are people actually around" when scheduling a
| meeting outside of your culture.
| Tor3 wrote:
| 1) Daylight saving time has absolutely nothing to do with
| this, and in any case a lot of people, me included, are
| of the opinion that DST is a Bad Thing and should be
| abolished.
|
| 2) If you want to let everybody in the world know when
| something specific happens (e.g. the launch of the first
| manned Mars mission), then you specify the time in UTC.
| But.. that's what we do already. Or at least those with
| some sense. There's still no need to force Joe Nobody to
| get to work at 14:00 (assuming a single world time zone)
| when the sun rises.. there's no advantage for people
| elsewhere in the world. You yourself argued that "most
| people aren't scheduling phone calls or meetings with
| unfamiliar locations". So, what's the advantage here?
|
| 3) I happen to use a calendar which is coordinated with
| others - it happens automatically, when they schedule
| something. And it has zero problem with the time - it's
| not just date. There's zero to gain by using UTC as
| localtime everywhere. That does nothing for the calendar.
|
| 4) Cultural differences in work hours: They absolutely
| exist. So what would having everybody use UTC help with?
| You _still_ have to know those differences. It 's even
| worse then, because if my stepson tells me "I have to
| work to 10AM" then I know it's late, for him. I know it
| instantly. If he had said "..have to work to 13 UTC" then
| I'm lost. I don't immediately see that he's actually
| working very late. I'll have to think "let's see.. he's
| in Tokyo, so that would be, hmm, this many hours
| difference from here.. is there an issue here? Oh wait,
| "you're working really late, will you be you okay?"
|
| 5) And that statement ".. most people aren't scheduling
| phone calls or meetings with unfamiliar locations".
| That's false. We're not in the 19th or even the 20th
| century anymore. The internet is a thing, and tons of
| people are in _daily_ contact with people from all over
| the world. Just a moment ago I got a message from an
| airbnb guest, for example.
| andix wrote:
| You could also argue that different languages need to go away.
| Would make everything easier.
| IgorPartola wrote:
| It is much harder to do. We all speak the same 24 hour clock
| and it is not a culturally significant thing. It would be
| nice if everyone could understand everyone but there is
| something to be lost by losing languages. There is absolutely
| nothing to be lost by doing away with timezones.
| vundercind wrote:
| Of course there's something lost. If I see my colleague's
| local time will be 9:00PM, I know not to schedule a meeting
| then. It's a method for translating familiar associations
| of hours across space.
|
| Also, and more importantly, "it's 5:00 somewhere!" would
| cease to be true.
| michaelt wrote:
| _> Timezones are 19th century thinking. We can do better._
|
| That's why I only use Swatch(tm) Internet Beats [1] for
| timekeeping.
|
| Now if you'll excuse me, I have a @583.32 meeting to get to.
|
| [1] https://en.wikipedia.org/wiki/Swatch_Internet_Time
| ta1243 wrote:
| Meetings tend to start at most at quarter-hour intervales, or
| about 1/100th of a day.
|
| If everyone used swatch times meetings would tend to start at
| intervals of 20, or maybe tens. Your meeting would start at
| @580 and last until @600 rather than 1300 to 1330 or
| whatever.
| pavel_lishin wrote:
| May I recommend you read this article titled "So You Want To
| Abolish Time Zones"?
|
| https://qntm.org/abolish
| coldpie wrote:
| I like the point of this article, but it takes a very long,
| winding, roundabout way to get there. I wish there was a
| better written article we could copy-paste when people make
| this suggestion.
|
| I guess what I mean is, I should write one.
| IgorPartola wrote:
| Look at it from the other direction for a moment: say we
| started with universal time. The whole world used UTC. Now
| try suggesting timezones. The idea would look absolutely
| insane. It would be a non-starter discussion.
|
| On the other hand the transition from timezones to UTC has
| some challenges but the idea itself is very worth
| considering. What does this tell you?
| Tor3 wrote:
| Why would that look insane at all? It's like saying that
| letting everybody everywhere be able to say "I work from
| nine to five" is insane. Or that saying that the date
| changes to the next day when it's midnight is insane.
| IgorPartola wrote:
| Because we had that. The reason GMT exists is because
| train stations in England all ran on different clocks.
| The train could leave at 11am and arrive at 10:55 at the
| next station because the clocks could be that far apart.
| And that was confusing so they said "hey you know what's
| a good idea? Having a coordinated time!"
|
| Going back to that would make things more confusing. You
| take it for granted that we all use the same calendar.
| Nobody signs your paycheck using the Chinese calendar,
| right? You likely agree that the US using the imperial
| system is silly because wouldn't the world be in a better
| place if we all used metric. So why the resistance to
| this?
| Tor3 wrote:
| Huh? We're arguing that timezones make sense and that
| keeping the world in a single timezone ("UTC everywhere")
| would not be a good option. You seemed to argue that if
| timezones hadn't already been invented then the idea of a
| local time would be insane. That's what I was replying
| to.
| teo_zero wrote:
| It would be an interesting experiment.
|
| You would have to give up many concepts that have local
| relevance, while gaining better understanding with non-local
| interlocutors. I think the balance depends on how many of your
| daily interactions happen at local or non-local scope.
|
| Swatch tried it in the 90s and failed. Maybe we are more
| globalized today...
| PopAlongKid wrote:
| >Say the tax brackets are rewritten for 2025, starting "January
| 1"
|
| U.S. income taxes are calculated on an annual basis, not
| hourly, so that is not an issue. (Wages are taxed according to
| when they are paid, which is a specific point in time, not
| according to when they were earned). A better example is trying
| to figure which calendar (tax) year an item of income or
| deduction belongs to. On tax professional forums, there are
| occasional discussions about what happens if I make a business
| payment online just before New Year's Day begins, but the
| recipient doesn't "constructively receive" it until after (or
| similar scenarios involving time zone differences). Do I get a
| deduction for the old year, but they have income in the new
| year? (The best answer, of course, is to not wait until a few
| hours before a deadline to conduct business transactions of
| this type, but not every type of business has that choice
| available).
| gorgoiler wrote:
| It seems like it would be so much easier to ship the tzdb
| algorithm as a single C library that could do arbitrary
| computation.
|
| Instead, the authors prefer to use their own domain language --
| source files with a compiler to a binary format with a reference
| parser implementation. The thrust of this article is that's
| mostly good enough but their domain language doesn't include
| lunar information.
|
| The downside would be size and runtime efficiency. I'm guessing
| tzdata is built the way it is so that it can be extremely small
| and efficient rather than large and, computationally speaking,
| comprehensive. You can run it on an Arm M0 as well as an Apple
| M2.
| kccqzy wrote:
| A lot of people appreciate the fact that whenever some random
| government decides to change of rule of their timezone (such as
| announcing DST changes), they only get a file update where the
| file is not powerful enough to be Turing complete instead of a
| C library update.
| gorgoiler wrote:
| That's a great point. For me though, these updates come via
| the same OS vendor channels that provided updated binaries
| too, so it's not like I'm dodging a recompile.
| fokker wrote:
| A fun read! My brother actually lives on Lord Howe Island along
| with his wife and 2 daughters. I'm visiting them in a few weeks
| too actually. I will share this tidbit with them haha.
| gonzo41 wrote:
| I lived in Hobart for a while and I was a firm proponent of
| having a Tassie south timezone that had a 2 hour winter shift to
| get some afternoon light. That six week pit in winter when the
| sun goes down at 430pm is tough.
| rswail wrote:
| For years I've been saying that a programming course is composed
| of two subjects:
|
| 1. Date and Time Programming
|
| 2. Debugging
|
| You will encounter every possible issue and common bug when doing
| #1, leading naturally to #2.
| twojastara wrote:
| GUWNO JEBANE
| grishka wrote:
| Another fun fact about timezones: if the government abolishes DST
| one year, and then moves some timezones an hour the next year, it
| creates a wild mess. Especially when you're building an Android
| app. Especially when it's the early 2010s so the timezone
| database is built into the system image but most devices that run
| your app don't receive system updates at all.
|
| Instead of picking the timezone with the correct offset and no
| DST, many people would adjust the time itself so the wrong
| timezone and the wrong unixtime cancel each other out so the
| clock "looks right". Not fun when you're doing math with
| timestamps, some of which are local and some come from the
| server.
| jandrese wrote:
| I worked with a group of people once who just didn't care about
| timezones. All (ok, most) clocks were set to local time, but
| with some random timezone, about half of the time it was GMT,
| and 2/3 of the remainder were our actual timezone, but the rest
| were totally random. I had to write a "figure out what the time
| actually is" routine in my code because it was such a pervasive
| problem.
| grishka wrote:
| I ended up doing kinda the same. Our API already had a method
| to retrieve the current unixtime on the server, which I used,
| together with the user-set timezone, to figure out the UTC
| offset that the user _actually meant to set_ by adjusting
| their clock.
| lxgr wrote:
| This makes me wonder: Should NTP servers broadcast the tz
| database...? (And should the tz database support a stable but
| turing-complete scripting/bytecode language?)
| ironmagma wrote:
| That sounds like the beginning of a story that ends with an
| RCE.
| lxgr wrote:
| Hey, if OpenType fonts get to do it, why shouldn't
| timezones? :)
| Aidevah wrote:
| > Unless you're doing some fairly exotic things where you're
| finding yourself saying things like
|
| >> Oh yeah the OCR on Japanese driving licenses pops out things
| like "Ping Cheng 8", that's just how they sometimes say 1996
| over there. That's why we have this in the parser: eras = { "Da
| Zheng ": 1912, "Zhao He ": 1926, "Ping Cheng ": 1989 }
|
| >> One of these days we'll need to add "Ling He ": 2019, but it
| hasn't come up yet.
|
| Taiwan also uses the ROC calendar[1] which is directly descended
| from the regnal calendars of imperial china.
|
| But it's quaint that the Japanese name their year after one
| person, while us enlightened westerners simply use a calendar
| where it's simply the 2024th year of the, erm, hmmmph...
|
| [1] https://en.wikipedia.org/wiki/Republic_of_China_calendar
| sebastialonso wrote:
| Related to the subject, can anyone recommend a book about
| timezones? Not a technical, programming book, but one with the
| history of time zones and curious use cases?
| noleary wrote:
| It is not exactly what you're looking for, but long ago I read
| this book about the invention of the naval chronometer:
|
| https://en.m.wikipedia.org/wiki/Longitude_(book)
|
| It's generally pretty well-regarded and closely related.
| wbl wrote:
| _Revolution in Time_ is drier but still interesting and
| covers up past the quartz crisis starting from Babylon.
| lokar wrote:
| I recall working on some calendar software and finding that at
| some point in the past (you have to deal with all the rules from
| the past) a country (Saudi Arabia?) had an offset like every day
| to keep solar noon in line with civil time.
| Tepix wrote:
| I'd like to know the rationale behind these weird timezones, in
| particular non-hourly offsets to UTC. Why was it chosen that way?
| Why is it being upheld? It must be a big hassle.
|
| Why not switch to a normal 60 minute offset to UTC?
| ucarion wrote:
| tzdb often has the answer, and it's almost always because
| everyone used to do local solar time (i.e. on average, the sun
| is at the top of the sky at noon) until convenience (i.e. train
| and plane schedules) required an offset friendlier to mental
| math.
| pvaldes wrote:
| With the weirdest inhabitants like the legendary Lord Howe Island
| stick insect, AKA tree lobsters or more informally sausages with
| legs. A 20 cm long halloweenesque black beauty.
| 0xbadcafebee wrote:
| Ever since I was assigned to work on the school website's
| calendar when I was in high school, I have successfully avoided
| any software project having to do with time and date. I feel like
| my quality of life has been better for it.
| danielvaughn wrote:
| Just wait until we decide on a time zone for the moon, or Mars.
| perlgeek wrote:
| Mars days are longer than Earth days, so a time zone alone
| won't do.
|
| I think I actually heard on a podcast that some Mars rover
| mission team had to operate in shifts that were synchronized
| with Mars days.
| ak217 wrote:
| At some point the correct solution is for engineers to
| collectively agree to refuse to model government-prescribed
| deviations from convention. Or, put more obliquely, provide more
| feedback to make it more obvious who is bearing the cost of the
| complexity of these requirements.
|
| It's a social problem and it calls for a social solution.
|
| I know, there's a lot of disagreement around where the point in
| question is, but it would serve us well if more engineers were
| more assertive about stating their opinion on where it is.
| booleandilemma wrote:
| This sounds good until you realize that half or more of the
| software engineers are people working in 3rd world countries
| who just need a job, or they're H-1B's working in the US who
| can't afford to make waves.
|
| We would need to form some kind of global union and push back
| together.
| ak217 wrote:
| In the US there is a great example of a government agency
| that works to reduce emergent complexity in situations like
| this - NIST.
|
| NIST does a lot of work behind the scenes in advanced
| technical fields. I wonder if it would help if there was a
| NIST publication enumerating common time and date keeping
| patterns, like we have for cryptography.
| bcherry wrote:
| disagree - good products meet their users where they are and
| bury complexity under the hood. i can't imagine trying to use a
| calendar app (or any app really) that refuses to operate in any
| mode other than UTC.
| ak217 wrote:
| OK but most people would agree that "only UTC" is not an
| ergonomic default. There is a balance.
|
| Also, are the users where they are because they want to be
| there, or because long ago some government or religious
| leader forced something through and they go along with it
| because of some kind of inertia?
| heironimus wrote:
| Me: This does not look interesting at all, but its really
| popular, so I'll quickly skim it. Me, 5 mins later: I can't stop
| reading this!
| an-allen wrote:
| Obligatory - David Olsen and Paul Eggert - thank you for your
| service. The world literally works because of your efforts and I
| don't feel people really appreciate the ridiculous man made
| problem that you spent your labours to help resolve.
|
| If there was a Hall of Fame of OSS contributors - you would be in
| it sitting on top of a mountain. The Time Zone problem is a
| unique problem in that its not just a problem of whats the time
| in this location - its what was the time in this location 20, 50,
| 100 years ago. The level of scholarship and historical research
| you put into this library is really quite unmatched. Amazing
| folks you two. The whole world quite literally sits on the
| shoulders of you two giants.
|
| "Daylight Saving Time was first suggested as a joke by Benjamin
| Franklin in his whimsical essay "An Economical Project for
| Diminishing the Cost of Light" published in the Journal de Paris
| (1784-04-26). Not everyone is happy with the results." - Paul
| Eggert
| Lance_ET_Compte wrote:
| A thousand years ago, every village had their own timekeeping and
| it worked. Our village is now earth. What if we just abandoned
| daylight-savings time and timezones and just went with GMT (or
| anything else) for everywhere on earth?
|
| There would be cultural effects as people in California now start
| work at 16:00, for example...
| fermuch wrote:
| Isn't that how china works? One timezone for everyone
| ianburrell wrote:
| That is good example why one timezone doesn't work. The
| locals in Xinjiang use a local time zone +6, instead of China
| time +8, because the latter is too far off the daylight
| hours.
|
| My understanding is that use of Xinjiang time has dropped
| recently because of the crack down on Uygurs and government
| forcing China time.
| a57721 wrote:
| There are various countries that optimize the number of time
| zones for administrative purposes, but this is much easier
| and sensical to implement within one country than globally.
|
| UTC is used globally when it makes sense, e.g. for the
| schedules of international radio broadcasts.
| chanandler_bong wrote:
| This. 100%.
| cle wrote:
| The hard part is not doing it, it's getting people to agree. I
| highly doubt people will agree to do that, because a large
| portion of people don't agree with "our village is now Earth".
| tshaddox wrote:
| In order to do computing involving time zones you also need
| to get an enormous number of people (particularly vendors of
| computer operating systems and maintainers of programming
| languages) to agree. But yes, this does appear to be easier
| than getting a few hundred political jurisdictions to agree.
| soperj wrote:
| I'd adjust to that better than adjusting to Daylight savings
| time.
| bakkoting wrote:
| Here's a good essay about that: So You Want To Abolish Time
| Zones [1]
|
| [1] https://qntm.org/abolish
| ianburrell wrote:
| Everyone would create local time zones and use them. It is
| convenient to have the clock synchronized to the local day.
| Using UTC optimizes for long distances when people use local
| clocks much more often.
|
| How do you handle the date changing in the middle of the day?
| If I was on UTC, the date would change at 5pm. Is that still
| Wednesday or would it be Thursday?
|
| Also, it doesn't solve the problem since still need to figure
| out local time when interacting long distances. If need to keep
| track of local times, might as well use time zones.
|
| Finally, can solve most of the problems with time zones by
| including UTC time with anything long distance. Say "meeting is
| at 4pm, 23:00 UTC", then nobody has to worry about your local
| time zone.
| tshaddox wrote:
| > How do you handle the date changing in the middle of the
| day?
|
| It seems like you would have to do absolutely nothing? Just
| like you do absolutely nothing to "handle" the hour changing
| throughout the day. People work overnight shifts. People
| schedule important events close to and on either side of
| midnight.
| sethammons wrote:
| "did it happen wednesday the 23rd or wednesday the 24th?"
| tshaddox wrote:
| I wouldn't expect that confusion to be common. It's
| already common to say things like "I got terrible sleep
| on Wednesday night" even though some or all of the bad
| sleep might have happened after midnight and thus
| technically on Thursday.
| skissane wrote:
| > How do you handle the date changing in the middle of the
| day?
|
| In the Jewish and Islamic calendars, the day begins/ends at
| sunset, and hence the date changes at that point.
|
| Traditionally, (Western) astronomers used the astronomical
| day, going back to Ptolemy, in which a new day starts at
| noon. Part of the reason for this was that in pre-modern
| times it was a lot easier to precisely determine the moment
| of noon than the moment of midnight. Contemporary astronomy
| has mostly abandoned that tradition, but it still survives in
| the definition of Julian dates (but not Modified Julian dates
| which moved the day boundary to midnight)
| maxwell wrote:
| UTC is problematic since it splits the day: when it's midnight
| in Greenwich, it's still yesterday for half the world. The Unix
| epoch occurred in 1969 in Hawaii.
|
| BIT (UTC-12) is better. Only positive offsets. Everyone on the
| same day.
| throitallaway wrote:
| Our world has gotten smaller. For people that travel often and
| schedule calls across time zones, time zones are a complete
| pain in the ass. I've advocated for getting rid of time zones
| for ~10 years now. It really doesn't matter if people in
| California start work at 16:00; the people that live in that
| area will get used to it. Daylight will remain the same.
| autarch wrote:
| Time zones _without_ DST would be relatively easy to deal with.
| The answer is not "abolish time zones", it's just "abolish
| DST".
| chikere232 wrote:
| At some point, adding software support for these things is just
| enabling bad ideas. If there wasn't support for
| Australia/Lord_Howe they might be annoyed into picking a simpler
| time zone
| jmbwell wrote:
| Those interested in this kind of pedantry might also take care to
| note that it's called "daylight saving time," with no "s."
|
| It is a system of time for saving daylight.
|
| It is not a sales event promising "savings."
|
| Frustrating to read an otherwise excellent and detailed article
| that makes this error throughout.
| zokier wrote:
| Both forms are widely used and accepted. Wikipedia has whole
| section about that:
|
| https://en.wikipedia.org/wiki/Daylight_saving_time#Terminolo...
| kccqzy wrote:
| The most amusing tidbit about the tz database is that it contains
| an estimate of Big Bang, and it refuses to calculate timezone
| transitions occurring before the Big Bang.
|
| The commit message at
| https://github.com/eggert/tz/commit/b22d459a367f4d01b10f6f6b...
| says:
|
| > For example, Glib computes Sao Paulo time stamps as if Brazil's
| circa-1913 rules were still in effect. (Thanks to Leonardo
| Chiquitto for reporting the bug.) Work around the bug by not
| generating time stamps equal to -2**63. Come to think of it, time
| stamps before the Big Bang are physically suspect anyway, so
| don't generate time stamps before the Big Bang.
|
| Soon afterwards, a separate commit disallowed leap seconds before
| the Big Bang.
| ucarion wrote:
| This is really neat!
|
| Separately, I'm a little skeptical of the tzdb's endeavor of
| even thinking about pre-Unix-epoch stuff. The bug-to-utility
| ratio of that stuff doesn't seem to be there. `zic` is where
| most of the ugly gnarliness of tzdb lies, and I sometimes feel
| that it would have been better if `zic` weren't an artifact
| others could depend on.
| eikenberry wrote:
| That's a fun easter egg in the TZ database. I'd never heard of
| it, but how often do you need to calculate TZ data that old.
| Hopefully we'll be done with time zone's completely before the
| theory is outdated.
| mayneack wrote:
| My personal favorite timezones:
|
| There's UTC+14 in Micronesia:
| https://en.wikipedia.org/wiki/UTC%2B14:00
|
| Also Antarctica/Troll: A timezone for a norwegian research
| station. https://en.wikipedia.org/wiki/Time_in_Norway
| NotYourLawyer wrote:
| I'm so glad I don't have to think about this stuff for my day
| job. Just miserable.
| autarch wrote:
| > It's not like programming languages support representing
| 61-second minutes anyway
|
| This is not true. Someone already noted that Raku supports leap
| seconds. I think this may be partly my fault, because Perl 5's
| most popular datetime library, `DateTime.pm`, supports leap
| seconds.
|
| It's my fault because I created `DateTime.pm` and implemented its
| leap seconds support. In retrospect, this was almost certainly a
| mistake. Almost no one cares about leap seconds. It just produces
| all sorts of weird confusion. Like why does adding 60 seconds
| produce a different result than adding 1 minute, but only rarely?
|
| And it makes the code _way_ more complicated, especially since I
| wanted to validate whether setting second to 60 was valid.
|
| This seems simple. Why not just look up the leap second table and
| check? Well, the `DateTime` constructor takes time components
| (including `second => 60`) and _any_ time zone. So we have to
| convert the date/time passed to the constructor to UTC in order
| to do that lookup. But doing that conversion ... ended up
| involving values that include leap seconds because of historical
| reasons.
|
| It's a huge mess for very little gain.
|
| As to Raku, I think it's stdlib datetime library borrowed from
| Perl 5's `DateTime.pm` quite heavily so it inherits some of the
| same bad design decisions.
| Loughla wrote:
| I like that you did it and can look back with a more elegant
| solution.
|
| What was the thought process originally? Were you just too
| focused on the problem?
|
| I find that if I'm too close to the problem and too focused for
| [arbitrary timeframe], this is the type of thing that happens.
| The joy of fixing something before it's broken takes over.
| autarch wrote:
| I wrote this code in the early 2000s, so I don't remember the
| exact thought process. But I think my thinking was something
| along the lines of "this is a thing that exists, therefore I
| should model it 100% accurately". But I think the right way
| to think about it is "this is a thing that exists but most
| developers would be better off never thinking about,
| therefore I should omit it entirely".
|
| Of course, the _real_ correct solution is to split up a
| date/time library into a number of closely related
| classes/structs, and allow users to pick the one that meets
| their needs. So most folks would pick the leap second-free
| class, but a few would use the one with leap seconds baked
| in.
| lizmat wrote:
| Raku has the [Instant](https://docs.raku.org/type/Instant)
| class:
|
| "An Instant is a particular moment in time measured in atomic
| seconds, with fractions. It is not tied to or aware of any
| epoch."
| 0x70dd wrote:
| Correctly ingesting and visualizing data that's captured by
| different devices while also accounting for travel across
| timezones, is a real challenge. [1] is our guide how we do this
| for diabetes data generated by CGMs and insulin pumps.
|
| [1] https://tidepool.stoplight.io/docs/tidepool-
| api/branches/mas...
| tdeck wrote:
| > Morocco and Gaza do their daylight savings based on Ramadan.
|
| Something about this doesn't make sense. My understanding is that
| Ramadan can happen at any season of the year (imagine fasting all
| day in Greenland during the summer!) because the Islamic calendar
| doesn't insert intercalary months like many other "lunar"
| calendars do. Given that, what is the benefit of having a
| daylight savings time at all if it's tied to the lunar calendar?
| Isn't the idea of DST tied to day length?
___________________________________________________________________
(page generated 2024-10-30 23:01 UTC)