тип данных "время,но не GMT а звёздное"

[Andromed]

тип данных "время,но не GMT а звёздное"

я работаю с обработкой наблюдательных данных в обсерватории

мне нужнем тип данных для хранения времени в формате "часы-минтуы-секуныды", но вся, так сказать,
соль в том, что в звёздных сутках не 24 часа, а 23ч 56м 4с
Так же есть тружности с замедлением вращения земли, прецессией и тп - но это пока меня не интерсует

по сути нужен тип данных времени в котором сутки дляться не 24 часа, а 23ч 56м 4с и нет високосного года (нету дня 29 февраля )

воопрос следующий : существет ли такой тип данных в mysql или в других реализациях языка sql ?

 

[akd]

собственно, возможно глупый вопрос, но что мешает хранить "звездное" время в поле для обыного времени?

 

[Andromed]

Автор оригинала: akd
собственно, возможно глупый вопрос, но что мешает хранить "звездное" время в поле для обыного времени?

вопрос не глупый)

дело в том что обсерватория работает по звёздному времени, а не по московскому и соответственно все данные должны так же храниться "в звёздном времени". Возникает проблема преобразования GMT в звёзное и наоборот, а операции
SELECT WEEK () или SELECT DATE_ADD не годятся

маленькая справочка: смысл звёздного времени в том, что если,допустим, наблюдается объект на небе (звезда,пульсар),то по звёздному времени этот объект всегда находится в одной точке на небе в одно и то же время.

ps забыл упомянуть, что в звёздном времени нет перехода на летнее/зимнее время

 

[Fortop]

дело в том что обсерватория работает по звёздному времени, а не по московскому и соответственно все данные должны так же храниться "в звёздном времени".

Ну и пусть хранятся. Кто мешает?
Можете еще и триггер поставить, чтобы при попытке записи времени больше чем 23ч 56м 4с ничего не писалось.

Возникает проблема преобразования GMT в звёзное и наоборот

Проблема где? Преобразование когда происходит?

SELECT WEEK () или SELECT DATE_ADD не годятся

Ну не годятся, так не годятся, напишите свои аналоги для работы с звездным временем.

 

[Andromed]

Автор оригинала: Fortop
Ну не годятся, так не годятся, напишите свои аналоги для работы с звездным временем.

CпасибО КапитаН ОчевидностЬ

Вопрос был в том,существует ли такой тип данных в sql или нет, необязательно в mysql.

 

[dimagolov]

Andromed, собственно можно было и догадаться, что под столь хитрую задачу готовых решений не будет.

Надеюсь, Вы в курсе, что время храниться в unix timestamp. Так как Вам придется опираться на системное время, которое доступно по NTP, то придется и звездное время хранить в unix timestamp. GMT/UTC корректируется на процессию вращения, но это вам только в плюс.
Реально Вас не должно устраивать только то, как unix timestamp пересчитывается в год/месяц/день/час/минута/секунда.
ИМХО решить это проще всего патчами исходников тех пакетов, которые Вы используете, скажем MySQL и PHP в той части, которая отвечает за работу с данными.

 

[Andromed]

Автор оригинала: dimagolov


Надеюсь, Вы в курсе, что время храниться в unix timestamp. Так как Вам придется опираться на системное время, которое доступно по NTP, то придется и звездное время хранить в unix timestamp. GMT/UTC корректируется на процессию вращения, но это вам только в плюс.
Реально Вас не должно устраивать только то, как unix timestamp пересчитывается в год/месяц/день/час/минута/секунда.
ИМХО решить это проще всего патчами исходников тех пакетов, которые Вы используете, скажем MySQL и PHP в той части, которая отвечает за работу с данными.

да, я примерно так и представлял себе это, но у меня 2 момента вызывают неясность:
1. вряд ли получится, и не знаю пока на сколько это может пригодится, но всё-таки у нас в обсерватории служба времени работает не с 70го года, а годов с 50х -60х (точно не знаю, но принципиально что unix timestamp не оперерует в этом диапазоне дат )
2. я, к сожадению, не уверен в своих силах в программировани на столько, чтобы написать патч правящий и добавлюяющий свои типы данных в sql . Просьба дайте ссылку - где можно почитать что-либо по этому поводу

 

[fixxxer]

Зачем что-то патчить?

Берешь нормальную СУБД, позволяющую определять свои типы данных (PostgreSQL, например), и реализуешь что надо.

Алгоритмы конвертации GMT-GST вроде как известные.

Кстати, отрицательные timestamp-ы никто не отменял (винду на помойку).

 

[Andromed]

то есть , если я правильно вас понял, в PostgreSQL можно определить свой тип данных?

а отрицательные timestamp-ы - это получается "до нашей эры" ? )

спасибо, почитаю учебник PostgreSQL

 

[dimagolov]

а отрицательные timestamp-ы - это получается "до нашей эры"

это до 1/1/1970 GMT

 

[Andromed]

нет,я о том что "наша эра" для timestamp - это 1970 (аналогия с нумерацией годов )