Daylight savings date identification over the net

Indeed. BTDTGTTS.

From being involved with telecom accounting we made a very good decision early on. EVERY log file has UTC times internally, and as they are forwarded from the various controllers to the accounting systems. The accounting system also works in UTC.

The timezones may then be added ona per-user base just before the finished print. Or not. It is simple to make the accounting periods follow UTC in the contracts.

-- mrr

Why does everyone confuse the displayed time with the time stored in a file or database and assume they are the one and the same ?

If possible, you should always store away timestamps in one permanent timezone, say GMT, and then use the timezone database to determine what the local time offset is from that stored time.

That way, there are no jumps in the (say) on-disk recorded time regardless of any timezone changes. Linux does this (and I believe Unix in general does as well) and it works cleanly.

BTW, I have a VMS background and I have seen first hand the mess that is timezone handling when you assume displayed time equals stored time. :-)

Simon.

Except that in some domains all days are 24 hours long (or in one case all days are about 23 hours, 56 minutes, and 4 seconds long)

Unless they are dealing in UT1, which does NOT have leap seconds.

Yes, knowing that other answers (for other definitions) are possible is good, but for a very reasonable definition of month and year, 12 IS the answer.

Looking at other answers you have accepted, you are demonstrating another bias, for example one answer to the number of days in a year is 1/2.

I've been considering GMT, rather than local time. I guess I should have read the title of the thread!

I didn't know you could get two leap seconds in one year. It is not uncommon to see time utilities, RTC's, etc., that support seconds counts in the range 0..60 so that they can handle a leap second - but not two leap seconds (see "man date" for example - and that's a *nix command, not a recommended google search....).

I suppose it is also possible for a lost leap second to give 59 seconds in a minute on occasion.

In 1972 one second was added after Jun 30 and an other second after Dec 31. Technically, one could add 12 leap seconds in one year, each after any month, but always only one second at a time.

I agree basically, the thing is that our spectrometers are completely self-sufficient, they do run an OS (DPS) with its filesystem, UI etc., one can access them from any platform which has a VNC viewer application (windows, linux, android have been used so far).

Obviously time is stored as UTC - in directory entries, within spectra etc., however one has to deal also with the time for user interpretation. File dates are preferred in local time (usually I suppose, so far so good with that). On spectrum evaluation results the time is accompanied by the GMT offset so there is no ambiguity there either (pretty much like time was defined in rfc822 I think, except for leaving out the leading 0 of the hours - a mistake I have made many years ago which I have not had to fix yet and leave so in the hope the world will catch up with my better representation :D :D ).

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

------------------------------------------------------

This is the only sane solution, this is how DPS (the OS under which our devices work) maintains time. In the newer (longnamed) directory entry type time is stored in uS since Jan 1 1970, 64 bits. Current devices do not support the entire precision but the format is there. Older (shortnamed) directories store seconds. Somewhere in the 90-s (the initial format of the shortnamed - 8.4 - directory entry was set in 1994 or 1995) I had to bite the bullet and change to seconds since 1.1.1970, had not thought enough of it when starting the entire endeavour. I think even now the old format can be recognized and read more or less correctly from old disks...

Yes, once one has the correct unambiguous data representation is just a matter of choice.

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

------------------------------------------------------

Sure, but that is not everyday (or perhaps every semiyear!) experience for the "man on the Clapham omnibus", whereas

If they can't get everyday experience right, there's no point in considering the "subtleties"!

If they know the concept of UT1, they'll know the rest - or at least know they have to go and research the answer. That's fine by me.

I'm not aware of anything other than 12 being used for civil purposes, but some calendars do contain 13 months.

Unless you're thinking of non-terrestrial calendars, you'll have to explain that one!

No need for an explanation, then :-)

(It's Mercury, to save you looking it up.)

Yet another example of "10% more difficult than expected, recursively"!

Suspected so, couldn't be bothered to google :)

\>>>

Actually every day IS about 23 hours, 56 minutes and 4 seconds long, IF you are dealing with Sidereal days.

If you are saying that Sidereal days aren't important because they aren't and "everyday experience", then neither are other than 12 months to a year.

Yep, you were showing a Terran bias.

The original question was about calendars, and I'm not aware of any calendars based on the sidereal day.

But that could be another example of the "10% recursive"!

I haven't said that, of course.

Do you have any pointers to non-terran calendars?

Yes. There's the calender as used on Mars.

Simon.

And before someone thinks I've lost the plot :-), Google for

NASA living on Mars time

(and similar search strings)

at which point you will find NASA employees have some direct experience of living by a Mars calender. :-)

Simon.

If it isn't in the tz database, it doesn't exist. Bah.

Oh, if you insist :)

Must try and get some astrologers to define what it means to have "Earth in the ascendent" and not "Mars in the ascendent" :) And it that's astrological gibberish, then... ... how can anybody tell?

(No. I'm not going to google it. On principle.)

I'm sure they just keep the RTC running GMT or local standard time and just adjust for DLS by massaging that data and NOT messing with the RTC, but that may be too much for a small MCU to handle on the fly. I have done it the "bad" way, which can drift the clock a few seconds per year, on top of the clock's drift, depending on how fast you can pull it all off. I have a DLS flag held in the RTC's free battery backed RAM and I check the time and date against that flag and actually update the RTC accordingly. I wrote a set of routines to check if the date and time falls inside the DLS period and go from there. I saw one implementation that just hard coded the next 10 years of DLS dates and times in a lookup table and adjusted the RTC accordingly.

I do have one product that I just don't do it, the owner just adjusts the time when they go to collect the cash in the unit. Which is usually weekly.

Then why were there questions about seconds in a minute or hours in a day, these are not calendar questions either.

Here are some found with a bit of searching.

Of course, until we get to some other planet, or meet someone who has, these will be be a bit academic. The "Working on Mars Time", was interesting, while the period was short enough they really didn't get to calendars, they did get to clocks.

The number of hours in a day depends on the day of the year - hence calendar information is inherently required That is reflected in the API of software libraries; many default to a particular locale but allow you to set the locale.

Um, I was looking for something with at least a tiny basis in reality.

I suspected as much.

Anything less fictional? Astrological calendars don't count!

Actually, if you look up the definitions of hours, and day, you should find that for most reasonable definitions of "day", you will get that a day is 24 hours (for earth) for EVERY day. It is only for this strange beasty of a "calendar day", or something artificial like "wall clock time" that we get the exception, and this strangeness. You also need to add into the equation where you are talking about, as there are locations which never to this shifting, and others that do it at other times, so just having a calendar isn't good enough.

So, you say that just because you haven't meet the people using the calendar it doesn't exist? At that point you need to accept that a person may consider that there are always 12 months in a year, and even that as far as they are concerned, always 24 hours in a day (they may be from a place without DST).